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Abstract 


This document is a revised version of RFC 2301. The revisions, 
summarized in the list attached as Annex B, are based on discussions 
and suggestions for improvements that have been made since RFC 2301 
was issued in March 1998, and on the results of independent 
implementations and interoperability testing. 


This RFC 2301 revision describes the Tag Image File Format (TIFF) 
representation of image data specified by the International 
Telecommunication Union (ITU-T) Recommendations for black-and-white 
and color facsimile. This file format specification is commonly 
known as TIFF for Fax eXtended (TIFF-FX). It formally defines 
minimal, extended, and lossless Joint Bi-level Image experts Group 
(JBIG) profiles (Profiles S, F, J) for black-and-white fax and base 
JPEG, lossless JBIG, and Mixed Raster Content profiles (Profiles C, 
L, M) for color and grayscale fax. These profiles correspond to the 
content of the applicable ITU-T Recommendations. 
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1. Introduction 


This document describes the use of TIFF (Tag Image File Format) to 
represent the data content and structure generated by the current 
suite of ITU-T Recommendations for Group 3 facsimile. These 
recommendations and the TIFF fields described here support the 
following facsimile profiles: 


S: 


Bee 


ws 


Minimal black-and-white profile, using binary MH compression 
EA] 

Extended black-and-white profile, using binary MH, MR, and MMR 
compression [T.4, T.6] 

Lossless JBIG black-and-white profile, with JBIG compression 
[T.85, T.82] 

Lossy color and grayscale profile, using JPEG compression [T.42, 
T.81] 

Lossless color and grayscale profile, using JBIG compression 
[T.43, T.82] 

Mixed raster content profile [T.44], using a combination of 
existing compression methods 


Each profile corresponds to the content of ITU-T Recommendations 
shown and is a subset of the full TIFF for facsimile specification. 


Profile S describes a minimal interchange set of fields, which will 
guarantee that, at least, binary black-and-white images will be 
supported. Implementations are required to support this minimal 
interchange set of fields. 


With the intent of specifying a file format for Internet fax, this 


document 

1. specifies the structure of TIFF files for facsimile data, 

2. defines ITU fax-compatible values for existing TIFF fields, and 

3. defines new TIFF fields and values required for compatibility with 


ITU color fax. 
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This specification of TIFF for facsimile is known as TIFF-FX (TIFF 
for Fax eXtended). References to the format described by this 
specification should always use the term "TIFF-FX", and some profiles 
in this specification may not be interpreted correctly by other TIFF 
applications. 


1.1. Scope 


This document defines a TIFF-based file format specification for 
enabling standardized messaging-based fax over the Internet. It 
specifies the TIFF fields and field values required for compatibility 
with the existing ITU-T Recommendations for Group 3 black-and-white, 
grayscale, and color facsimile. TIFF has historically been used for 
handling fax image files in applications such as store-and-forward 
messaging. Implementations that support this file format 
specification for import/export may elect to support it as a native 
format. This document recommends a TIFF file structure compatible 
with low-memory and page-level streaming implementations. 


Unless otherwise noted, the current TIFF specification [TIFF] and 
selected TIFF Technical Notes [TIN1, TIN2] are the primary references 
for describing TIFF and defining TIFF fields. This document is the 
primary reference for defining TIFF field values for fax 
applications. 


1.2. Approach 


The basic approach to using TIFF for facsimile data is to insert the 
compressed fax image data into a TIFF file and use TIFF fields to 
encode the parameters that describe the image data. These fields 
will have values that comply with the ITU-T Recommendations. 


This approach takes advantage of TIFF features and structures that 
bridge the data formats and performance requirements of both legacy 
fax machines and host-based fax applications. TIFF constructs for 
pages, images, and strips allow a TIFF file to preserve the fax data 
stream structure and the performance advantages that come with it. A 
TIFF-based approach also builds on an established base of users and 
implementors and ensures backward compatibility with existing TIFF- 
based IETF proposals and work in progress for Internet fax. 


1.3. Overview of this Document 
Section 2 gives an overview of TIFF. Section 2.1 describes the 
structure of TIFF files, including general guidelines for structuring 


multi-page TIFF files. Section 2.2 lists the TIFF fields that are 
required or recommended for all fax profiles. The TIFF fields used 
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only by specific fax profiles are described in Sections 3 - 8, which 
describe the individual fax profiles. These sections also specify 
the ITU-compatible field values (image parameters) for each profile. 


The full set of permitted fields of TIFF for facsimile are included 
in the current TIFF specification, Section 2 of this document, and 
the sections on specific profiles of facsimile operation. This 
document defines profiles of TIFF for facsimile, where a profile is a 
subset of the full set of permitted fields and field values of TIFF 
for facsimile. 


Section 3 defines the minimal black-and-white facsimile profile 
(Profile S), which is required in all implementations. Section 4 
defines the extended black-and-white fax profile (Profile F), which 
provides a standard definition of TIFF-F. Section 5 describes the 
lossless black-and-white profile using JBIG compression (Profile J). 


Section 6 defines the base color profile, required in all color 
implementations, for the lossy JPEG representation of color and 
grayscale facsimile data (Profile C). Section 7 defines the lossless 
JBIG color and grayscale facsimile profile (Profile L), and Section 8 
defines the Mixed Raster Content facsimile profile (Profile M). Each 
of these sections concludes with a table summarizing the required and 
recommended fields for each profile and the values they can have. 


Section 9 refers to the MIME content types used in connection with 
TIFF for facsimile. Sections 10 and 11 give Security Considerations 
and References, followed by Authors’ Addresses and the Copyright 
Notice. Annex A gives a summary of the TIFF fields used or defined 
in this document and provides a convenient reference for 
implementors. 


To implement only the minimal interchange black-and-white set of 
fields and values (Profile S), one need read only Sections 1, 2, 3, 
9, and 10. 


The following tree diagram shows the relationship among profiles and 
between profiles and coding methods. 
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S (MH) 
IN 
B&W / \ Color 
/ \ \ 
/ F (MH, MR, MMR) C (JPEG) 
/ IN 
J (JBIG) === \ 
/ \ 
L (JBIG) \ 
\ 
M (MRC) 


A profile is based on a collection of ITU-T facsimile coding methods. 
For example, Profile S, the minimal profile, is based on Modified 
Huffman (MH) compression, which is defined in ITU-T Rec. T.4. 

Profile F specifies Modified Huffman (MH), Modified READ (MR), and 
Modified Modified READ (MMR) compressions, which are defined in ITU-T 
Rec. T.4 and T.6. 


All implementations of TIFF for facsimile MUST implement Profile S, 
which is the root node of the tree. All color implementations of 
TIFF for facsimile MUST implement Profile C. The implementation of a 
particular profile MUST also implement those profiles on the path 
that connect it to the root node, and MAY optionally implement 
profiles not on the path connecting it to the root node. For 
example, an implementation of Profile M must also implement Profiles 
C and S and may optionally implement Profile F, J, or L. For another 
example, an implementation of Profile C must also implement Profile S 
and may optionally implement Profile F or J. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", " NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [REO]. 

2. TIFF and Fax 


2.1. TIFF Overview 


TIFF provides a means for describing, storing, and interchanging 
raster image data. A primary goal of TIFF is to provide a rich 


environment within which applications can exchange image data. The 
current TIFF specification [TIFF] defines a commonly used core set of 
TIFF fields known as Baseline TIFF. The current specification, the 


set of Pagemaker TIFF Technical Notes [TIN1], and TIFF Technical Note 
2 [TIN2] define several TIFF extensions. The TIFF-based 
specification for fax applications uses a subset of Baseline TIFF 
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fields, with selected extensions, as described in this document. In 
a few cases, this document defines new TIFF fields specifically for 
fax applications. 


2.1.1. File Structure 


TIFF is designed for raster images, which makes it a good match for 
facsimile documents, which are multi-page raster images. Each raster 
image consists of a number of rows or scanlines, each of which has 
the same number of pixels, the unit of sampling. Each pixel has at 
least one sample or component (exactly one for black-and-white 
images). 


A TIFF file begins with an 8-byte image file header. The first two 
bytes describe the byte order used within the file. Legal values are 
"II" (0x4949) when bytes are ordered from least to most significant 
(little-endian), and "MM" (0x4D4D), when bytes are ordered from most 
to least significant (big-endian) within a 16- or 32-bit integer. 
Either byte order can be used, except in the case of the minimal 
black-and-white profile, which SHALL use value "II". The next two 
bytes contain the value 42, which identifies the file as a TIFF file 
and is ordered according to the value in the first two bytes of the 
header. The last four bytes give the offset that points to the first 
image file directory (IFD). This and all other offsets in a TIFF 
file are with respect to the beginning of the TIFF file. An IFD can 
be at any location in the file after the header but must begin on a 
word boundary. 


An IFD is a sequence of tagged fields, sorted in ascending order by 
tag value. An IFD consists of a 2-byte count of the number of 
fields, a sequence of field entries, and a 4-byte offset to the next 
IFD. The fields contain information about the image and pointers to 
the image data. Each separate raster image in the file is 
represented by an IFD. 


Each field entry in an IFD has 12 bytes and consists of a 2-byte Tag, 
2 bytes identifying the field type (e.g., short, long, rational, 
ASCII), 4 bytes giving the count (number of values or offsets), and 4 
bytes containing either the offset to a field value stored outside 
the IFD or, based on the type and count, the field value itself. 
Resolution and metadata such as dates, names, and descriptions are 
examples of "long" field values that do not fit in 4 bytes and 
therefore use offsets in the field entry. Details are given in the 
TIFF specification [TIFF]. 


A TIFF file can contain more than one IFD, where each IFD is a 


subfile whose type is given in the NewSubfileType field. Multiple 
IFDs can be organized either as a linked list, with the last entry in 
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each IFD pointing to the next IFD (the pointer in the last IFD is 0), 
or as a tree, using the SubIFDs field in the primary IFD [TIN1]. The 
SubIFDs field contains an array of pointers to child IFDs of the 
primary IFD. 


Child IFDs describe related images, such as reduced resolution 
versions of the primary IFD image. The same IFD can point both to a 
next IFD and to child IFDs, and child IFDs can themselves point to 
other IFDs. 


All fax profiles represent a multi-page fax image as a linked list of 
IFDs, with a NewSubfileType field containing a bit that identifies 
the IFD as one page of a multi-page document. Each IFD has a 
PageNumber field, identifying the page number in ascending order, 
starting at 0 for the first page. Although a Baseline TIFF reader is 
not required to read any IFDs beyond the first, an implementation 
that reads the files that comply with this specification SHALL read 
multiple IFDs. Only the Mixed Raster Content fax profile, described 
in Section 8, requires the use of child IFDs. 
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2. 


1 


The following figure illustrates the structure of a multi-page TIFF 
file. 


AZ ------- + 
| Header | ------------ + 
+---------------------—-— + | First IFD 
| IFD (page 0) |<----------- + Offset 
+--- | | ------------ + 

Value | === 2253953929 ===2====3= + 

Offset +-->| Long Values |--+ 
Po 555225222820 ==55=5 | | Strip | 
| Image Data |<-+ Offset | 
| strip 1 page 0 | | | 
Ho + | | 
| : | | 
AEREA aie Reais aaa n + Next IFD 
| IFD (page 1) |< A + Offset 

+--- | | ------------ + 

Value | Pe SSS TSH Sass SESH TSS F | 

Offset +-->| Long Values |--+ | 
A E S | Strip | 
| Image Data <-+ Offset 
| strip 1 page 1 | | | 
Ho + | | 
| strip 2 page 1 |<-+ | 
Ho + | | 
| : | | 
4+----------------------- + | Next IFD 
| IFD (page 2) |< SS == === + Offset 
| : | 

.2. Image Structure 


An IFD stores an image as one or more strips, as shown in the 
preceding figure. A strip consists of 1 or more scanlines (rows) of 
raster image data in compressed form. An image may be stored ina 
single strip or may be divided into several strips, which would 
require less memory to buffer. (Baseline TIFF recommends about 8k 
bytes per strip, but existing fax usage is typically one strip per 
image.) 


Each IFD requires three strip-related fields: StripOffsets, 
RowsPerStrip, and StripByteCounts. The StripOffsets field is an 
array of pointers to the strip or strips that contain the actual 
image data. The StripByteCounts field gives the number of bytes in 
each strip after compression. TIFF requires that each strip, except 
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the last, contain the same number of scanlines, which is given in the 
RowsPerStrip field. This document introduces the new StripRowCounts 
field that allows a variable number of scanlines per strip, which is 
required by the Mixed Raster Content fax profile (Section 8). 


Image data is stored as uninterpreted, compressed image data streams 
within a strip. The formats of these streams follow the ITU-T 
Recommendations. The Compression field in the IFD indicates the type 
of compression, and other TIFF fields in the IFD describe image 
attributes such as color encoding and spatial resolution. 

Compression parameters are stored in the compressed data stream 
rather than in TIFF fields. This makes the TIFF representation and 
compressed data format specification independent of each another. 
This approach, modeled on [TIN2], allows TIFF to add new compression 
schemes gracefully as they become available. 


Some attributes can be specified both in the compressed data stream 
and within a TIFF field. It is possible that the two values will 
differ. When this happens for values required to interpret the data 
stream, the values in the data stream take precedence. For 
informational values that are not required to interpret the data 
stream, such as author name, then the TIFF field value takes 
precedence. 


2.1.3. TIFF File Structure for Fax Applications 


The TIFF specification has a very flexible file structure that does 
not specify the ordering of IFDs, field values, and image data in a 
file. Individual applications may require or recommend an ordering. 


This specification recommends that when using a TIFF file for 
facsimile, a multi-page fax document SHOULD be represented as a 
linked list of IFDs. It also recommends that a TIFF file for 
facsimile SHOULD order pages in a TIFF file in the same way that they 
are ordered in a fax data stream. Ina TIFF file, a page consists of 
several elements: one or more IFDs (including subIFDs), long field 
values that are stored outside the IFDs, and image data (in one or 
more strips). 


The minimal black-and-white profile (Profile S) specifies a required 
ordering of pages and elements within a page (Section 3.5). The 
extended black-and-white profile (Profile F) provides guidelines for 
ordering pages and page elements (Section 4.4.6). Other profiles 
SHOULD follow these guidelines. This recommendation is intended to 
simplify the implementation of TIFF writers and readers in fax 
applications and the conversion between TIFF file and fax data stream 
representations. However, for interchange robustness, readers SHOULD 
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be prepared to read TIFF files whose structure is consistent with 
[TIFF], which supports a more flexible file structure than is 
recommended here. 


This specification introduces an optional new GlobalParametersIFD 
field, defined in Section 2.2.4. This field has type IFD and 
indicates parameters describing the fax session. While it is often 
possible to obtain these parameters by scanning the file, it is 
convenient to make them available together in one place for fast and 
easy access. If the GlobalParametersIFD occurs ina TIFF file, it 
SHOULD be located in the first IFD, immediately following the 8-byte 
image file header. 


2.2. TIFF Fields for All Fax Applications 


The TIFF specification [TIFF] is organized as a baseline set and 
several extensions, including technical notes [TIN1, TIN2] that will 
be incorporated in the next release of TIFF. The baseline and 
extensions have required and optional fields. 


Facsimile applications require (and recommend) a mixture of baseline 
and extensions fields, as well as some new fields that are not part 
of the TIFF specification and that are defined in this document. 

This sub-section lists the fields that are required or recommended 
for all profiles. In particular, Section 2.2.1 lists the fields that 
are required by all profiles and that have values that do not depend 
on the profile. Section 2.2.2 lists the fields that are required by 
all profiles and that have values that do depend on the profile. 
Section 2.2.3 lists the fields that are recommended for all profiles. 
Fields required or recommended by some but not all profiles are given 
in the section (Section 3 - 8) that describes that profile. The 
sections for each fax profile have subsections for required and 
recommended fields; each subsection organizes the fields according to 
whether they are baseline, extension or new. 


The fields required for facsimile have only a few legal values, 
specified in the ITU-T Recommendations. Of these legal values, some 
are required and some are optional, just as they are required 
(mandatory) or optional in fax implementations that conform to the 
ITU-T Recommendations. The required and optional values are noted in 
the sections on the different fax profiles. 
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This section describes the fields required or recommended by all fax 
profiles. The pattern for the description of TIFF fields in this 
document is as follows: 


FieldName (TagValueInDecimal) = allowable values. 
TYPE 


WhetherRequiredByTIFForTIFFforFAX 

Count = (omitted if =1) = (if not in current spec but available) 
Explanation of the field, how it's used, and the values it can 
have. Default value, if any, as specified in [TIFF]. 


When a field’s default value is the desired value, that field may be 
omitted from the relevant IFD unless specifically required by the 
text of this specification. 


2.2.1. TIFF fields required for all fax profiles 


The TIFF fields listed in this section SHALL be used by all fax 
profiles but have field values that are not specified by the ITU 
standards, i.e., the fields do not depend on the profile. The next 
subsection lists the fields that SHALL be used by all fax profiles, 
but which do have values specified by the ITU-specified or profile- 
specific values. Fields that SHALL be used by some but not all 
profiles are given in the Sections (3 - 8) that describe the profiles 
that use them. 


ImageLength (257) 

SHORT or LONG 
RequiredByTIFFBaseline 
Total number of scanlines in image. 
No default, must be specified. 


PageNumber (297) 


SHORT 
RequiredByTIFFforFAX, TIFFExtension 
Count = 2 


The first number represents the page number (0 for the first 
page); the second number is the total number of pages in the 
document. If the second value is 0, then the total page count is 
not available. 

No default, must be specified 
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2 


2 


RowsPerStrip(278) 

SHORT or LONG 
RequiredByTIFFBaseline 
The number of scanlines per TIFF strip, except for the last strip. 
For a single strip image, this is the same as the value of the 
ImageLength field. 
Default = 2**32 - 1 (meaning all scanlines in one strip). 


StripByteCounts (279) 
SHORT or LONG 
RequiredByTIFFBaseline 


Count = number of strips 
For each strip, the number of bytes in that strip after 
compression. 


No default, must be specified. 


StripOffsets (273) 
SHORT or LONG 
RequiredByTIFFBaseline 
Count = number of strips 
For each strip, the byte offset from the beginning of the file to 
the start of that strip. 
No default, must be specified. 


-2. Additional TIFF fields required for all fax profiles 


The TIFF fields listed in this section SHALL be used by all fax 
profiles, but the values associated with them depend on the profile 


being described and the associated ITU Recommendations. Therefore, 
only the fields are defined here; the values applicable to a 
particular fax profile are described in Sections 3 - 8. Fields that 


SHALL be used by some but not all profiles are given in the section 
(3 - 8) describing the profile that uses them. 


BitsPerSample (258) 
SHORT 
RequiredByTIFFBaseline 
Number of bits per image sample. 
Default = 1 (field may be omitted if this is the value). 


Compression (259) 
SHORT 
RequiredByTIFFBaseline 
Compression method used for image data. 
Default = 1 (no compression, so may not be omitted for FAX). 
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FillOrder (266) 

SHORT 

RequiredByTIFFforFax 

The default bit order in Baseline TIFF per [TIFF] is indicated by 
FillOrder=1, where bits are not reversed before being stored. 
However, TIFF for Fax typically uses the setting of FillOrder=2, 
where the bit order within bytes is reversed before storage (i.e., 
bits are stored with the Least Significant Bit first). 

Default = 1 (field may be omitted if this is the value) 

Facsimile data appears on the phone line in bit-reversed order 
relative to its description in the relevant ITU compression 
Recommendation. Therefore, a wide majority of facsimile 
implementations choose this natural order for storage. 


Nevertheless, all readers conforming to this specification must be 
able to read data in both bit orders, except in the case of 
Profile S, which only requires support for FillOrder=2 (Least 
Significant Bit first). 


ImageWidth (256) 

SHORT or LONG 
RequiredByTIFFBaseline 
The number of pixels (columns) per scanline (row) of the image 
No default, must be specified. 


NewSubFileType (254) 

LONG 
RequiredByTIFFforFAX 
A general indication of the kind of data contained in this IFD Bit 
1 is 1 if the image is a single page of a multi-page document. 
Default = 0 (no subfile bits on, so may not be omitted for FAX). 


PhotometricInterpretation (262) 

SHORT 
RequiredByTIFFBaseline 
The color space of the image data. 
No default, must be specified. 


ResolutionUnit (296) 


SHORT 
RequiredByTIFFBaseline The unit of measure for resolution. 2 = 
inch, 3 = centimeter; Default = 2 (field may be omitted if this is 


the value) 
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SamplesPerPixel (277) 

SHORT 
RequiredByTIFFBaseline 
The number of color components per pixel; SamplesPerPixel is 1 for 
a black-and-white, grayscale or indexed (palette) image. Default 
= 1 (field may be omitted if this is the value). 


XResolution (282) 

RATIONAL 
RequiredByTIFFBaseline 
The horizontal resolution of the image in pixels per resolution 
unit. The ITU-T Recommendations for facsimile specify a small 
number of horizontal resolutions: 100, 200, 300, 400 pixels per 
inch, and 80, 160 pixels per centimeter (or 204, 408 pixels per 
inch). The allowed XResolution values for each profile are given 
in the section defining that profile. Per [T.4], it is 
permissible for applications to treat the following XResolution 
values as being equivalent: <204, 200> and <400,408> in 
pixels/inch. These equivalencies were allowed by [T.4] to permit 
conversions between inch and metric based facsimile terminals. To 
ensure interoperability, if an application accepts any member of 
the pairs then T.4 requires it to accept both (e.g., accept 204 if 
200 pixels per inch is accepted). TIFF for Facsimile Writers 
SHOULD express XResolution in inch-based units, for consistency 
with historical practice and to maximize interoperability. See 
the table below for information on how to convert from an ITU-T 
metric value to its inch-based equivalent resolution. 
No default, must be specified 


YResolution (283) 

RATIONAL 
RequiredByTIFFBaseline 
The vertical resolution of the image in pixels per resolution 
unit. The ITU-T Recommendations for facsimile specify a small 
number of vertical resolutions: 100, 200, 300, 400 pixels per 
inch, and 38.5, 77, 154 pixels per centimeter (or 98, 196, 391 
pixels per inch). The allowed YResolution values for each profile 
are given in the section defining that profile. Per [T.4], it is 
permissible for applications to treat the following YResolution 
values as being equivalent: <98, 100>, <196, 200>, and <391, 400> 
in pixels/inch. These equivalencies were allowed by [T.4] to 
permit conversions between inch- and metric-based facsimile 
terminals. To insure interoperability, if an application accepts 
any member of the pairs, then T.4 requires it to accept both 
(e.g., accept 98 if 100 pixels per inch is accepted). TIFF for 
Facsimile Writers SHOULD express YResolution in inch-based units, 
for consistency with historical practice and to maximize 
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See the table below for information on 


converting from the metric value to its inch based equivalent 


resolution. 


No default, must be specified. 


tana O AZ O + 
| XResolution | YResolution 
$ $ $ $ + 
ResolutionUnit |ResolutionUnit |ResolutionUnit |ResolutionUnit 
=2 (inch) =3 (cm) =2 (inch) =3 (cm) 
$ $ $ $ + 
| 100 | | 100 | | 
$2 $ $ $ + 
| 204 | 80 | 98 | 38.5 
| 200 | | 100 | | 
$ $2 $ hs= =p + 
| 204 | 80 | 196 | 77 
| 200 | | 200 | | 
$2 $2 $ $ + 
| 204 | 80 | 391 | 154 
$ $ $ $2 + 
| 300 | | 300 | | 
$ $2 $ $ + 
| 408 | 160 | 391 | 154 
| 400 | | 400 | | 
E $ $ $ + 


.3. TIFF fields recommended for all fax profiles 


The TIFF fields listed in this section MAY be used by all fax 


profiles. However, Profile S writers 
described in Section 3) 


SHOULD NOT use these fields. 


(the minimal fax profile 
Recommended 


fields that are profile-specific are described in Sections 3 - 8. 


DateTime (306) 
ASCII 
OptionalInTIFFBaseline 


Date/time of image creation in 24-hour format 


"YYYY:MM:DD HH:MM:SS". No default. 


DocumentName (269) 
ASCII 


OptionalInTIFFExtension (DocumentStorageAndRetrieval) 


The name of the scanned document. 
not a Baseline TIFF field. 
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No default. 
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ImageDescription (270) 

ASCII 
OptionalInTIFFBaseline 
A string describing the contents of the image. 
No default. 


Orientation(274) = 1 - 8. 

SHORT 
OptionalinTIFFBaseline 1: Oth row represents the visual top of the 
image; the Oth column represents the visual left side of the 
image. See the current TIFF spec [TIFF] for further values; 
Baseline TIFF only requires value=1. Default = 1. 
Note: It is recommended that a writer that is aware of the 
orientation include this field to give a positive indication of 
the orientation, even if the value is the default. Writers should 
not generate mirror images, because many readers will not properly 
reverse the image before display or print. 


Software (305) 
ASCII 
OptionalInTIFFBaseline 
The name and release number of the software package that 
created the image. 
No default. 


2.2.4. New TIFF fields recommended for fax profiles 


The new TIFF fields listed in this section MAY be used by all fax 
profiles. However, Profile S writes (the minimal fax profile 
described in Section 3) SHOULD NOT use these fields. In addition, 
support for these new TIFF fields has not been included in historical 
TIFF-F readers described in Section 4 and [TIFF-F]. These fields 
describe "global" parameters of the fax session that created the 
image data. They are optional, not part of the current TIFF 
specification, and are defined in this document. 


The first new field, GlobalParametersIFD, is an IFD that contains 
global parameters and is located in a Primary IFD. 


GlobalParametersIFD (400) IFD or LONG 
An IFD containing global parameters. It is recommended that a 
TIFF writer place this field in the first IFD, where a TIFF reader 
would find it quickly. 
Each field in the GlobalParametersIFD is a TIFF field that is 


legal in any IFD. Required baseline fields should not be located 
in the GlobalParametersIFD but should be in each image IFD. Ifa 
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conflict exists between fields in the GlobalParametersIFD and in 
the image IFDs, then the data in the image IFD shall prevail. 


Among the GlobalParametersIFD entries is a new ProfileType field 
that generally describes information in this IFD and in the TIFF 
file. 


ProfileType (401) 
LONG 
The type of image data stored in this IFD. 
0 = Unspecified 
1 = Group 3 fax 
No default 


The following new global fields are defined in this document as IFD 
entries for use with fax applications. 


FaxProfile(402) = 0 - 6. 

BYTE 
The profile that applies to this file; a profile is subset of the 
full set of permitted fields and field values of TIFF for 
facsimile. The currently defined values are: 
0: does not conform to a profile defined for TIFF for facsimile 

minimal black € white lossless, Profile S 

extended black & white lossless, Profile F 

lossless JBIG black & white, Profile J 

lossy color and grayscale, Profile C 

lossless color and grayscale, Profile L 

Mixed Raster Content, Profile M 


NUP WN EH 


CodingMethods (403) 

LONG 
This field indicates which coding methods are used in the file. A 
value of 1 in a bit location indicates the corresponding coding 
method is used. More than one bit set to 1 means more than one 
coding method is used in the file. 

Bit 0: unspecified compression 


Bit 1: 1-dimensional coding, ITU-T Rec. T.4 (MH - Modified Huffman) 
Bit 2: 2-dimensional coding, ITU-T Rec. T.4 (MR - Modified READ) 
Bit 3: 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified MR) 

Bit 4: ITU-T Rec. T.82 coding, using ITU-T Rec. T.85 (JBIG) 

Bit 5: ITU-T Rec. T.81 (Baseline JPEG) 

Bit 6: ITU-T Rec. T.82 coding, using ITU-T Rec. T.43 (JBIG color) 
Bits 7 - 31: reserved for future use 
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Note: There is a limit of 32 compression types to identify standard 
compression methods. 


VersionYear (404) 

BYTE 
Count: 4 
The year of the standard specified by the FaxProfile field, given 
as 4 characters, e.g., '1997'; used in lossy and lossless color 
profiles. 


ModeNumber (405) 

BYTE 
The mode of the standard specified by the FaxProfile field. A 
value of 0 indicates Mode 1.0; used in Mixed Raster Content 
profile. 


3. Profile S: Minimal Black-and-White Fax Profile 


This section defines the minimal black-and-white subset of TIFF for 
facsimile. This subset is designated Profile S. All implementations 
of TIFF for facsimile SHALL support the minimal subset. 


Black-and-white mode is the binary fax application most users are 
familiar with today. This mode is appropriate for black-and-white 
text and line art. Black-and-white mode is divided into two levels 
of capability. This section describes the minimal interchange set of 
TIFF fields that must be supported by all implementations in order to 
assure that some form of image, albeit black-and-white, can be 
interchanged. This minimum interchange set is a strict subset of the 
fields and values defined for the extended black-and-white profile 
(TIFF-F or Profile F) in Section 4, which describes extensions to the 
minimal interchange set of fields that provide a richer set of 
black-and-white capabilities. 


3.1. Overview 


The minimal interchange portion of the black-and-white facsimile mode 
supports 1-dimensional Modified Huffman (MH) compression, with the 
original Group 3 fax resolutions, commonly called "standard" and 
"fine." 


To assure interchange, this profile uses the minimal set of fields 
with a minimal set of values. There are no recommended fields in 
this profile. Further, the TIFF file is required to be "little- 
endian", which means that the byte order value in the TIFF header is 


"II". This profile defines a required ordering for the pages ina 
fax document and for the IFDs and image data of a page. It also 
requires 
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that a single strip contain the image data for each page; see Section 
3.5. The image data may contain RTC sequences, as specified in 
Section 3.4. 


3.2. Required TIFF Fields 


Besides the fields listed in Section 2.2.1, the minimal black-and- 
white fax profile requires the following fields. The fields listed 
in Section 2.2.1 and the fields and fax-specific values specified in 
this subsection must be supported by all implementations. 


3.2.1. Baseline fields 


BitsPerSample(258) = 1. 
SHORT 
RequiredByTIFFBaseline 
Binary data only. 
Default = 1 (field may be omitted if this is the value) 


Compression(259) = 3. 

SHORT 
RequiredByTIFFBaseline 
3 = 1- or 2- dimensional coding. 
The value 3 is a TIFF extension value [TIFF]. The T4Options field 
must be specified, and its value specifies that the data is 
encoded with the Modified Huffman (MH) compression of [T.4]. 


FillOrder (266) = 2. 
SHORT 
RequiredByTIFFBaseline 
2 = Least Significant Bit first 


NOTE: Baseline TIFF readers are only required to support FillOrder 
1, where the lowest numbered pixel is stored in the MSB of the 
byte. However, because many devices, such as modems, transmit the 
LSB first when converting the data to serial form, it is common 
for black-and-white fax products to use the second FillOrder = 2, 
where the lowest numbered pixel is stored in the LSB. Therefore, 
this value is specified in the minimal black-and-white profile. 


ImageWidth(256) = 1728. 

SHORT or LONG 
RequiredByTIFFBaseline 
This profile only supports a page width of 1728 pixels. This 
width corresponds to North American Letter and Legal and to ISO A4 
size pages. No default, must be specified. 
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NewSubFileType (254) = (Bit 1=1). 
LONG 
RequiredByTIFFforFAX 
Bit 1 is 1 if the image is a single page of a multi-page document. 


Default = 0 (no subfile bits on, so may not be omitted for fax). 
PhotometricInterpretation(262) = 0. 
SHORT 


RequiredByTIFFBaseline 
0 = pixel value 1 means black. 
No default, must be specified. 


ResolutionUnit (296) = 2. 
SHORT 
RequiredByTIFFBaseline 
The unit of measure for resolution. 2 = inch. 
Default = 2 (field may be omitted if this is the value). 


SamplesPerPixel (277) = 1. 

SHORT 
RequiredByTIFFBaseline 
The number of components per pixel; 1 for black-and-white. 
Default = 1 (field may be omitted if this is the value). 


XResolution(282) = 200, 204. 

RATIONAL 
RequiredByTIFFBaseline 
The horizontal resolution of the image is expressed in pixels per 
resolution unit. In pixels/inch, the allowed values are 200 and 
204, which may be treated as equivalent. See Section 2.2.2 for 
inch metric equivalency. No default, must be specified. 


YResolution(283) = 98, 100, 196, 200. 

RATIONAL 
RequiredByTIFFBaseline The vertical resolution of the image is 
expressed in pixels per resolution unit. In pixels/inch, the 


allowed values are 98, 100, 196, and 200; 98 and 100 may be 
treated as equivalent, and 196 and 200 may be treated as 
equivalent. See Section 2.2.2 for inch metric equivalency. No 
default, must be specified. 
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3.2.2. Extension fields 


T4Options (292) = (Bit 0 = 0, Bit 1 = 0, Bit 2 = 0, 1) 
LONG 
RequiredTIFFExtension (when Compression = 3) 
Bit 0 = 0 indicates MH compression. 


Bit 1 must be 0. 

Bit 2 = 1 indicates that EOLs are byte aligned, = 0 EOLs not byte 
aligned. 

Default is all bits are 0 (applies when EOLs are not byte aligned) 


Note: The T4Options field is required when the Compression field has 
a value of 3. Bit 0 of this field specifies the compression used (MH 
only in this profile). MH coding requires the use of EOL (End of 
Line) codes: Bit 2 indicates whether the EOL codes are byte-aligned 
or not. See Section 3.4 for details. 


3.2.3. New Fields 
None. 
3.3. Recommended TIFF Fields 
None. 
3.4. End of Line (EOL) and Return to Control (RTC) 


TIFF extensions for fax, used in this specification, differ from 
Baseline TIFF in the following ways: 


- A 12-bit EOL sequence MUST precede each line of MH-compressed 
image data. (Baseline TIFF does not use these EOL sequences.) 

- The EOL sequence MAY be byte-aligned, in which case fill bits are 
added so that the EOL sequence ends on a byte boundary, and any 
subsequent image data begins on a byte boundary. 

- If the EOL codes are not byte aligned, the image data MAY be 
followed by an RTC (Return to Control) sequence, consisting of 6 
consecutive EOLs. 


In conventional fax, an MH-compressed fax data stream for a page 
consists of the following sequence: 
EOL, compressed data (first line), EOL, compressed data, ... , 
EOL, compressed data (last line), RTC (6 consecutive EOL codes) 


Baseline TIFF does not use EOL codes or Return to Control (RTC) 
sequences for MH-compressed data. However, the TIFF extension field 
T40ptions used in this specification for MH compression (Compression 
= 3) requires EOLs. 
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Furthermore, Bit 2 in the T4Options field indicates whether or not 
the EOL codes are byte aligned. If Bit 2 = 1, indicating the EOL 
codes are byte aligned, then fill bits have been added as necessary 
before EOL codes so that an EOL code always ends on a byte boundary, 
and the first bit of data following an EOL begins on a byte boundary. 
Without fill bits, an EOL code may end in the middle of a byte. Byte 
alignment relieves application software of the burden of bit-shifting 
every byte while parsing scanlines for line-oriented image 


manipulation (such as writing a TIFF file). Not all TIFF readers 
historically used for fax are able to deal with non byte aligned 
data. 


While TIFF extension requires EOL codes, TIFF in fax applications has 
traditionally prohibited RTC sequences. Implementations that seek 
common processing and interfaces for fax data streams and Internet 
fax files would prefer that the TIFF data include RTC sequences. 


To reconcile these differences, RTCs are allowed in cases where EOL 
codes are not byte aligned and no fill bits have been added to the 
data. This corresponds to situations where the fax data is simply 
inserted in a strip without being processed or interpreted. RTCs 
should not occur in the data when EOLs have been byte aligned. This 
is formally specified in the next subsection. 


3.4.1. RTC Exclusion 


Implementations that seek to maintain strict conformance with TIFF 
and compatibility with the historical use of TIFF for fax SHOULD NOT 
include the RTC sequence when writing TIFF files. However, 
implementations that need to support "transparency" of T.4-generated 
image data MAY include RTCs when writing TIFF files if the flag 
settings of the T4Options field are set for non byte aligned data, 
i.e., Bit 2 is 0. Implementors of TIFF readers should be aware that 
there are some existing TIFF implementations for fax that include the 
RTC sequence in MH image data. Therefore, minimal set readers MUST 
be able to process files that do not include RTCs and SHOULD be able 
to process files that do include RTCs. 


3.5. File Structure 


The TIFF header, described in Section 2.1.1, contains two bytes that 
describe the byte order used within the file. For the minimal 
black-and-white profile, these bytes SHALL have the value "II" 
(0x4949), denoting that the bytes in the TIFF file are in LSByte- 
first order (little-endian). The first or Oth IFD immediately 
follows the header, so offset to the first IFD is 8. The header 
values are shown in the following table: 
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Ho ===> ie n aoe Ho O i + 
| Offset | Description | Value 

+-------- AZ Ho ===> Ho + 
| 0 | Byte Order | 0x4949 (IT) | 
Ho $ Ho ===> Ho + 
| 2 | Identifier | 42 decimal 
+-------- A Ho ===> Ho + 
| 4 | Offset of Oth IFD | Ox 0000 0008 | 
+-------- $ Ho ===> Ho + 


The minimal black-and-white profile SHALL order IFDs and image data 
within a file as follows: (1) There SHALL be an IFD for each page in 


a multi-page fax document; (2) the IFDs SHALL occur in the same order 
in the file as the pages occur in the document; (3) the IFD SHALL 
precede the image data to which it has offsets; (4) the image data 


SHALL occur in the same order in the file as the pages occur in the 
document; (5) the IFD, the value data, and the image data to which it 
has offsets SHALL precede the next image IFD; and (6) the image data 
for each page SHALL be contained within a single strip. 


As a result of (6), the StripOffsets field will contain the pointer 
to the image data. With two exceptions, the field entries in the IFD 
contain the field values instead of offsets to field values located 
outside the IFD. The two exceptions are the values for the 
XResolution and YResolution fields, both of which are type RATIONAL 
and require 2 4-byte numbers. These "long" field values SHALL be 
placed immediately after the IFD which containing the offsets to 
them, and before the image data pointed to by that IFD. 


The effect of these requirements is that the IFD for the first page 
SHALL come first in the file after the TIFF header, followed by the 
long field values for XResolution and YResolution, followed by the 
image data for the first page, then the IFD for second page, and so 
on. This is shown in the following figure. Each IFD is required to 
have a PageNumber field, which has value 0 for the first page, 1 for 
the second page, and so on. 
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4+----------------------- + 
| Header | ------------ + 
Ho oo + | First IFD 
| IFD (page 0) | <---------- + Offset 
+--- | | ------------ + 
eo eee | 
Value | aa a ae a AN a + | | 
Offset +-->| Long Values po] | 
eS SSS SS SS SS == | Strip 
| Image Data (page 0) <-+ Offset 
4----------------------- + | Next IFD 
| IFD (page 1) | <---------- + Offset 
+---| | ------------ + 
| | [+ | 
Value | Pane S SSH sr SSS SSS aS GSS + | | 
Offset +-->| Long Values | 
tates See ee oe ee Strip 
| Image Data (page 1) |<-+ Offset | 
4+----------------------- + | Next IFD 
| IFD (page 2) | <---------- + Offset 


Using this file structure may reduce the memory requirements in 
implementations. It also provides some support for streaming, in 
which a file can be processed as it is received and before the entire 
file is received. 


3.6. Profile S: Minimal Black-and-White Profile Summary 


The table below summarizes the TIFF fields that compose the minimal 


interchange set for black-and-white facsimile. The Baseline and 
Extension fields and field values MUST be supported by all 
implementations. For convenience, certain fields that have a value 


that is a sequence of flag bits are shown with integer values 
corresponding to the flags that are set. An implementation should 
test the setting of the relevant flag bits individually, however, to 
allow extensions to the sequence of flag bits to be appropriately 


ignored. (See, for example, T4Options below.) 
Ho 4+—-------------------------------- + 
| Baseline Fields | Values 
Hon 4+—-------------------------------- + 
| BitsPerSample | 1 | 
Ho 4+-------------------------------- + 
Compression 3: 1D Modified Huffman coding 
set T4Options = 0 or 4 
$ = - - = 5 5 5 5 = + 
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+ SS a ee a ee oe ee eee et ree 


+ AH Sea A AN Se SS A eee 


+ A ea a E A a ge at os 


+ feed aa a PA A E ae Fs ed ia i E nt ep 


+ SSS SSS SS SSS SS SS SS SSS SS 


+ HA A A A A Se AS ee 
PhotometricInterpretation 
+ A A ae A A A ere 


+ A Stee ee ee A ee ee A ee 


+ E A IRE E ta ss es Se na ed ga sel op Se 


+ Sa a eee ae ae ee ey ee ee et ee ee 


+ eS Sa Se Se Se SS SO ee ee 


+ A Se am AA a Se A A A A ey A 


+ e a A a e il at et ee a GS nd lc e eae Ss E al ee 


+ A E A E E A A Sle se ed fe feng pe a St 


+ ed a a E em pls es nt aaa et ne E E et ii] at les et oe 


+ HA Se Sr ee ee et ee ee 


Profile F: 


FillOrder 
ImageWidth 


ImageLength 


NewSubFileType 


PageNumber 


ResolutionUnit 


RowsPerStrip 


SamplesPerPixel 
StripByteCounts 


StripOffsets 


XResolution 
YResolution 
Extension Fields 


T40ptions 


File Format for Internet Fax 


in image 


+ —— + —+—+ 


2: Bit 1 identifies single 


February 2005 


== + 


2: least significant bit first | 


n: total number of scanlines | 


==> + 


page of a multi-page document 


total page count m 


offset from beginning of 
file to single TIFF strip 


204, 200 (pixels/inch) 


+ — + — + —— + — + — + —— + — + — + — + 
= 


aligned 


+ ——— + 


Extended Black-and-White fax profile 


----- + 


n,m: page number n followed by | 


----- + 


0: pixel value 1 means black | 


number of scanlines per strip | 
= ImageLength, with one strip | 


number of bytes in TIFF strip | 


----- + 


----- + 


98, 196, 100, 200 (pixels/inch) | 


0: MH coding, EOLs not byte | 


4: MH coding, EOLs byte aligned | 


----- + 


This section defines the extended black-and-white profile or Profile 
It provides a standard definition of what 
has historically been known as TIFF Class F and now as TIFF-F. In 


F of TIFF for facsimile. 


doing so, 


it aligns this profile with current ITU-T Recommendations 


for black-and-white fax and with existing industry practice. 
Implementations of this profile include implementations of Profile S. 
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This section describes extensions to the minimal interchange set of 
fields (Profile S) that provide a richer set of black-and-white 
capabilities. The fields and values described in this section are a 
superset of the fields and values defined for the minimal interchange 
set in Section 3. In addition to the MH compression, Modified READ 
(MR) and Modified Modified READ (MMR) compression, as described in 
[T.4] and [T.6] are supported. 


Section 4.1 gives an overview of TIFF-F. Section 4.2 describes the 
TIFF fields that SHALL be used in this profile. Section 4.3 
describes the fields that MAY be used in this profile. In the spirit 
of the original TIFF-F specification, Sections 4.4 and 4.5 discuss 
technical implementation issues and warnings. Section 4.6 gives an 
example of TIFF-F use. Section 4.7 gives a summary of the required 
and recommended fields and their values. 


4.1. TIFF-F Overview 


Though it has been in common use for many years, TIFF-F has 
previously never been documented in the form of a standard. An 
informal TIFF-F document was originally created by a small group of 
fax experts led by Joe Campbell. The existence of TIFF-F is noted in 
[TIFF], but it is not defined. This document serves as the formal 
definition of the F application of [TIFF] for Internet applications. 
For ease of reference, the term TIFF-F will be used throughout this 
document as a shorthand for the extended black-and-white profile of 
TIFF for facsimile. 


Up until the TIFF 6.0 specification, TIFF supported various "Classes" 


that defined the use of TIFF for various applications. Classes were 
used to support specific applications. In this spirit, TIFF-F has 
been known historically as "TIFF Class F". Previous informal TIFF-F 


documents [TIFF-F0] used the "Class F" terminology. As of TIFF 6.0 
[TIFF], the TIFF Class concept has been eliminated in favor of the 
concept of Baseline TIFF. Therefore, this document updates the 
definition of TIFF-F as the F profile of TIFF for facsimile, by using 
Baseline TIFF as defined in [TIFF] as the starting point and then 
adding the TIFF extensions to Baseline TIFF that apply for TIFF-F. 
In almost all cases, the resulting definition of TIFF-F fields and 
values remains consistent with those used historically in earlier 
definitions of TIFF Class F. Where some of the values for fields 
have been updated to provide more precise conformance with the ITU-T 
[T.4] and [T.30] fax recommendations, these differences are noted. 
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4.2. Required TIFF Fields 


This section lists the required fields and the values they must have 
to be ITU-compatible. Besides the fields listed in Section 2.2.1, 
the extended black-and-white fax profile SHALL use the following 
fields. 


4.2.1. Baseline fields 


BitsPerSample(258) = 1. 
SHORT 
RequiredByTIFFBaseline 
Binary data only. 
Default = 1 (field may be omitted if this is the value) 


Compression(259) = 3, 4. 

SHORT 
RequiredByTIFFBaseline 
3 = 1- or 2- dimensional coding, must have T4Options field This is 
a TIFF Extension value [TIFF]. 
4 = 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified Modified 
READ, must have T6Options field)) This is a TIFF Extension value. 
Default = 1 (and is not applicable; field must be specified) 


NOTE: Baseline TIFF permits use of value 2 for Modified Huffman 
compression, but data is presented in a form that does not use EOLs, 
and so TIFF for facsimile uses Compression=3 instead. See Sections 
4.4.4, 4.5.1, and 4.5.2 for more information on compression and 
encoding. 


FillOrder(266) = 1 , 2. 
SHORT 
RequiredByTIFFBaseline 
Profile F readers must be able to read data in both bit orders, 
but the vast majority of facsimile products store data LSB first, 
exactly as it appears on the telephone line. 
1 = Most Significant Bit first. 
2 Least Significant Bit first. 


ImageWidth (256) 

SHORT or LONG 
RequiredByTIFFBaseline 
This profile supports the following fixed page widths: 1728, 2592, 
3456 (corresponding to North American Letter and Legal and ISO AZ 
paper sizes), 2048, 3072, 4096 (corresponding to ISO B4 paper 
size), and 2432, 3648, 4864 (corresponding to ISO A3 paper size). 
No default; must be specified. 
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NOTE: Historical TIFF-F did not include support for the following 
widths related to higher resolutions: 2592, 3072, 3648, 3456, 4096, 
and 4864. Historical TIFF-F documents also included the following 
values related to A5 and A6 widths: 816 and 1216. Per the most 
recent version of [T.4], A5 and A6 documents are no longer supported 
in Group 3 facsimile, so the related width values are now obsolete. 
See section 4.5.2 for more information on inch/metric equivalencies 
and other implementation details. 


NewSubFileType (254) = (Bit 1=1). 

LONG 
RequiredByTIFFforFAX 
Bit 1 is 1 if the image is a single page of a multi-page document. 
Default = 0 (no subfile bits on, so may not be omitted for fax). 


NOTE: Bit 1 is always set to 1 for TIFF-F, indicating a single page 
of a multi-page image. The same bit settings are used when TIFF-F is 
used for a one-page fax image. See Section 4.4.3 for details on 
multi-page files. 


PhotometricInterpretation(262) = 0, 1. 
SHORT 
RequiredByTIFFBaseline 
0 = pixel value 1 means black, 1 = pixel value 1 means white. 


This field allows notation of an inverted or negative image. 
No default, must be specified. 


ResolutionUnit (296) = 2, 3. 
SHORT 
RequiredByTIFFBaseline 
The unit of measure for resolution. 2 = inch, 3 = centimeter; = 
TIFF-F has traditionally used inch-based measurement. 
Default = 2 (field may be omitted if this is the value). 


SamplesPerPixel (277) = 1. 

SHORT 
RequiredByTIFFBaseline 
1 = monochrome, bi-level in this case (see BitsPerSample). 
Default = 1 (field may be omitted if this is the value). 


XResolution(282) = 200, 204, 300, 400, 408 

RATIONAL 
RequiredByTIFFBaseline 
The horizontal resolution of the image is expressed in pixels per 
resolution unit. In pixels/inch, the allowed values are 200, 204, 
300, 400, and 408. See Section 2.2.2 for inch metric equivalency. 
No default, must be specified. 
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NOTE: The values of 200 and 408 have been added to the historical 
TIFF-F values, for consistency with [T.30]. Some existing TIFF-F 
implementations may also support values of 80 pixels/cm, which is 
equivalent to 204 pixels per inch. See section 4.5.2 for information 
on implementation details. 


YResolution(283) = 98, 100, 196, 200, 300, 391, and 400 

RATIONAL 
RequiredByTIFFBaseline 
The vertical resolution of the image is expressed in pixels per 
resolution unit. In pixels/inch, the allowed values are 98, 100, 
196, 200, 300, 391, and 400 pixels/inch. See Section 2.2.2 for 
inch metric equivalency. 
No default, must be specified 


NOTE: The values of 100, 200, and 391 have been added to the 
historical TIFF-F values, for consistency with [T.30]. Some existing 
TIFF-F implementations may also support values of 77 and 38.5 (cm), 
which are equivalent to 196 and 98 pixels per inch, respectively. See 
section 4.5.2 for more information on implementation details. 


NOTE: Not all combinations of XResolution, YResolution, and 
ImageWidth are legal. The following table gives the legal 
combinations and corresponding paper sizes [T.30]. 


a E pos === =>===sH=2== Has====>=52====>==*+ >= =2823= + 
| XResolution x YResolution | ImageWidth 
Hn a 32 ARSS + SSS SSS aS SSS = Ho Ho Ho + 
| 200x100, 204x98 | | | | 
| 200x200, 204x196 | 1728 | 2048 | 2432 | 
| 204x391 | | | | 
$ ni iS Ho Ho Ho + 
| 300 x 300 | 2592 | 3072 | 3648 | 
do EE A A Ho Ho Ho + 
| 408 x 391, 400 x 400 | 3456 | 4096 | 4864 | 
PERRA ASS a === Hs Ho + 
|Letter,A4| B4 | a3 | 
| Legal | | | 
Ho Ho Ho + 
| Paper Size | 
$ O O TE + 
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4.2.2. Extension fields 


T40ptions(292) = (Bit 0 = 0 or 1, Bit 1 = 0, Bit 2 = 0 or 1) 
LONG 

RequiredTIFFExtension (when Compression = 3) 

T40ptions was also known as Group30ptions in a prior version of 
[TIFF]. 
Bit 0 = 1 indicates MR compression, = 0 indicates MH compression. 
Bit 1 must be 0. 
Bit 2 = 1 indicates that EOLs are byte aligned, = 0 EOLs not byte 


aligned. 
Default is all bits are 0 (applies when MH compression is used and 
EOLs are not byte aligned) (See Section 3.2.2.) The T4Options 


field is required when the Compression field has a value of 3. 
This field specifies the compression used (MH or MR) and whether 
the EOL codes are byte aligned or not. If they are byte aligned, 
then fill bits have been added as necessary so that the End of 
Line (EOL) codes always end on byte boundaries. See Sections 3.4, 
4.5.3, and 4.5.4 for details. 


T6éOptions (293) = (Bit 0 = 0, Bit 1 = 0). 
LONG 
RequiredTIFFExtension (when Compression = 4) 


Used to indicate parameterization of 2D Modified Modified READ 
(MMR) compression. T6Options was also known as Group4Options in a 
prior version of [TIFF]. Bit 0 must be 0. 

Bit 1 = 0 indicates uncompressed data mode is not allowed; = 1 
indicates that uncompressed data is allowed (see [TIFF]). Default 
is all bits 0. For FAX, the field must be present and have the 
value 0. The use of uncompressed data where compression would 
expand the data size is not allowed for FAX. 


NOTE: MMR compressed data is two-dimensional and does not use EOLs. 
Each MMR encoded image MUST include an "end-of-facsimile-block" 
(EOFB) code at the end of each coded strip; see Section 4.5.6. 
4.2.3. New fields 
None. 
4.3. Recommended TIFF fields 


4.3.1. Baseline fields 


See Section 2.2.3. 


Buckley, et al. Standards Track [Page 32] 


RFC 3949 File Format for Internet Fax February 2005 


4.3.2. Extension fields 
See Section 2.2.3. 
4.3.3. New fields 
See Section 2.2.4 and optional fields below. 


Three new, optional fields, used in the original TIFF-F description 
to describe page quality, are defined in this specification. The 
information contained in these fields is usually obtained from 
receiving facsimile hardware (if applicable). They SHOULD NOT be 
used in writing TIFF-F files for facsimile image data that is error 
corrected or otherwise guaranteed not to have coding errors. Some 
applications need to understand exactly the error content of the 
data. For example, a CAD program might wish to verify that a file 
has a low error level before importing it into a high-accuracy 
document. Because Group 3 facsimile devices do not necessarily 
perform error correction on the image data, the quality of a received 
page must be inferred from the pixel count of decoded scanlines. A 
"good" scan line is defined as a line that, when decoded, contains 


the correct number of pixels. Conversely, a "bad" scanline is 
defined as a line that, when decoded, contains an incorrect number of 
pixels. 


BadFaxLines (326) 

SHORT or LONG 
The number of "bad" scanlines encountered by the facsimile device 
during reception. A "bad" scanline is defined as a scanline that, 
when decoded, comprises an incorrect number of pixels. Note that 


PercentBad = (BadFaxLines/ImageLength) * 100. 
No default. 

CleanFaxData(327) = 0, 1, 2. 

SHORT 


Indicates whether "bad" lines encountered during reception are 
stored in the data, or whether "bad" lines have been replaced by 
the receiver. 

0 = No "bad" lines 

1 = "bad" lines exist but were regenerated by the receiver, 

2 = "bad" lines exist but have not been regenerated. 

No default. 


NOTE: Many facsimile devices do not actually output bad lines. 
Instead, the previous good line is repeated in place of a bad line. 
Although this substitution, known as line regeneration, results ina 
visual improvement to the image, the data is nevertheless corrupted. 
The CleanFaxData field describes the error content of the data. That 
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is, when the BadFaxLines and ImageLength fields indicate that the 
facsimile device encountered lines with an incorrect number of pixels 
during reception, the CleanFaxData field indicates whether these bad 
lines are actually still in the data or whether the receiving 
facsimile device replaced them with regenerated lines. 


ConsecutiveBadFaxLines (328) 

LONG or SHORT 
Maximum number of consecutive "bad" scanlines received. The 
BadFaxLines field indicates only the quantity of bad lines. 
No Default. 


NOTE: The BadFaxLines and ImageLength data indicate only the quantity 
of bad lines. The ConsecutiveBadFaxLines field is an indicator of 
the distribution of bad lines and may therefore be a better general 
indicator of perceived image quality. See Section 4.4.5 for examples 
of the use of these fields. 


4.4. Technical Implementation Issues 
4.4.1. Strips 


In general, TIFF files divide an image into "Strips", also known as 
"bands". Each strip contains a few scanlines of the image. By using 
strips, a TIFF reader need not load the entire image into memory, 
enabling it to fetch and decompress small random portions of the 
image as necessary. 


The number of scanlines in a strip is described by the RowsPerStrip 
value and the number of bytes in the strip after compression by the 
StripByteCount value. The location in the TIFF file of each strip is 
given by the StripOffsets values. 


Strip size is application dependent. The recommended approach for 
multi-page TIFF-F images is to represent each page as a single strip. 
Existing TIFF-F usage is typically one strip per page in multi-page 
TIFF-F files. See Sections 2.1.2 and 2.1.3. 


4.4.2. Bit Order 
The current TIFF specification [TIFF] does not require a Baseline 
TIFF reader to support FillOrder=2, i.e., lowest numbered 1-bit pixel 


in the least significant bit of a byte. It further recommends that 
FillOrder=2 be used only in special purpose applications. 
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Facsimile data appears on the phone line in bit-reversed order 
relative to its description in ITU-T Recommendation T.4. Therefore, 
most facsimile applications choose this natural order for data ina 
file. Nevertheless, TIFF-F readers must be able to read data in both 
bit orders and support FillOrder values of 1 and 2. 


4.4.3. Multi-Page 


Many existing applications already read TIFF-F-like files but do not 
support the multi-page field. Since a multi-page format greatly 
simplifies file management in fax application software, TIFF-F 
specifies multi-page documents (NewSubfileType = 2) as the standard 
case. 


It is recommended that applications export multiple-page TIFF-F files 
without manipulating fields and values. Historically, some TIFF-F 
writers have attempted to produce individual single-page TIFF-F files 
with modified NewSubFileType and PageNumber (page one-of-one) values 
for export purposes. However, there is no easy way to link such 
multiple single-page files together into a logical multiple-page 
document, so this practice is not recommended. 


4.4.4. Compression 


In Group 3 facsimile, there are three compression methods which had 
been standardized as of 1994 and are in common use. The ITU-T T.4 
Recommendation [T.4] defines a one-dimensional compression method 
known as Modified Huffman (MH) and a two-dimensional method known as 
Modified READ (MR) (READ is short for Relative Element Address 
Designate). In 1984, a somewhat more efficient compression method 
known as Modified Modified READ (MMR) was defined in the ITU-T T.6 
Recommendation [T.6]. MMR was originally defined for use with Group 
4 facsimile, so that this compression method has been commonly called 
Group 4 compression. In 1991, the MMR method was approved for use in 
Group 3 facsimile and has since been widely utilized. 


TIFF-F supports these three compression methods. The most commonly 
used is the one-dimensional Modified Huffman (MH) compression method. 
This is specified by setting the Compression field value to 3 and 
then setting bit 0 of the T4Options field to 0. Alternatively, the 
two dimensional Modified READ (MR) method, which is much less 
frequently used in historical TIFF-F implementations, may be selected 
by setting bit 0 of the T4Options field to 1. The value of Bit 2 in 
this field is determined by the use of fill bits. 


Depending upon the application, the more efficient two-dimensional 


Modified Modified READ (MMR) compression method from T.6 may be 
selected by setting the Compression field value to 4 and then setting 
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the first two bits (and all unused bits) of the T60ptions field to 0. 
More information to aid the implementor in making a compression 
selection is contained in Section 4.5.2. 


Baseline TIFF also permits use of Compression=2 to specify Modified 
Huffman compression, but the data does not use EOLs. As a result, 
TIFF-F uses Compression=3 instead of Compression=2 to specify 
Modified Huffman compression. 


4.4.5. Example Use of Page-quality Fields 


Here are examples for writing the CleanFaxData, BadFaxLines, and 
ConsecutiveBadFaxLines fields: 


1. Facsimile hardware does not provide page-quality information: MUST 
NOT write page-quality fields. 


2. Facsimile hardware provides page-quality information, but reports 
no bad lines. Write only BadFaxLines = 0. 


3. Facsimile hardware provides page-quality information and reports 
bad lines. Write both BadFaxLines and ConsecutiveBadFaxLines. 
Also write CleanFaxData = 1 or 2 if the hardware’s regeneration 
capability is known. 


4. Source image data stream is error corrected or otherwise 
guaranteed to be error free such as for a computer-generated file: 
SHOULD NOT write page-quality fields. 


TIFF Writers SHOULD only generate these fields when the image has 
been generated from a fax image data stream where error correction, 
e.g., Group 3 Error Correction Mode, was not used. 


4.4.6. Practical Guidelines for Writing and Reading Multi-Page TIFF-F 
Files 


Traditionally, TIFF-F has required readers and writers to be able to 
handle multi-page TIFF-F files. The experience of various TIFF-F 
implementors has shown that implementing TIFF-F can be greatly 
simplified if certain practical guidelines are followed when writing 
multi-page TIFF-F files. 


The structure for a multi-page TIFF-F file will include one IFD per 
document page. In this case, this IFD will define the attributes for 
a single page. A second simplifying guideline is that the writer of 
TIFF-F files SHOULD present IFDs in the same order as the actual 
sequence of pages. (The pages are numbered within TIFF-F beginning 
with page 0 as the first page and then ascending (i.e., 0, 1, 
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2, ...). However, any field values over 4 bytes will be stored 
separately from the IFD. TIFF-F readers SHOULD expect IFDs to be 
presented in page order but be able to handle exceptions. 


Per [TIFF], the exact placement of image data is not specified. 
However, the offsets for each image strip are defined from within 
each IFD. Where possible, another guideline for TIFF-F writers is 
that the image data for each page of a multi-page document SHOULD be 
contained within a single strip (i.e., one image strip per fax page). 
A single image strip per page further simplifies TIFF-F file writing 
for applications such as store and forward messaging, where the file 
is usually prepared in advance of the transmission, but other 
assumptions may apply for the size of the image strip for 
applications that require "streaming" techniques (see section 4.4.7). 
If a different image strip size guideline has been used (e.g., 
constant size for image strips that may be less than the page size), 
this will immediately be evident from the values/offsets of the 
fields related to strips. 


Another simplifying guideline is that each IFD SHOULD be placed in 
the TIFF-F file structure at a point preceding the image that the IFD 
describes. 


In addition, placing the image data in a physical order within the 
TIFF file structure which is consistent with the logical page order 
simplifies TIFF-F file writing and reading. In practice, TIFF-F 
readers will need to use the strip offsets to find the exact physical 
location of the image data, whether or not it is presented in logical 
page order. 


If the image data is stored in multiple strips, then the strips 
SHOULD occur in the file in the same order that the data they contain 
occurs in the facsimile transmission, starting from the top of the 


page. 


TIFF-F writers MAY follow another simplifying guideline, in which the 
IFD, the value data and the image data to which the IFD has offsets 
precede the next image IFD. However, this guideline has been relaxed 
compared to the others given here. 


In the case of the minimal profile, which is also the minimal subset 
of Profile F, the SHOULDs and MAYs of these guidelines become SHALLS 
(see Section 3.5). 


A TIFF-F file structured using the guidelines of this section will 


essentially consist of a linked list of IFDs, presented in ascending 
page order, each pointing to a single page of image data 
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(one strip per page), where the pages of image data are also placed 
in a logical page order sequence within the TIFF-F file structure. 
(The pages of image data may themselves be stored in a contiguous 
manner, at the option of the implementor). 


7. Use of TIFF-F for Streaming Applications 


TIFF-F has historically been used for handling fax image files in 
applications such as store and forward messaging, where the entire 
size of the file is known in advance. Although TIFF-F may also be 
used as a file format for cases such as streaming applications, 
assumptions differing from those provided in this section (e.g., the 
entire size and number of pages within the image are not known in 
advance) may be required. As a result, a definition for the 
streaming application of TIFF-F is beyond the scope of this document. 


Implementation Warnings 
1. Uncompressed data 
TIFF-F requires the ability to read and write at least one- 
dimensional T.4 Huffman ("compressed") data. Uncompressed data is 


not allowed. The "Uncompressed" bit in T4Options or T6Options must 
be set to 0. 


-2. Encoding and Resolution 


Since two-dimensional encoding is not required for Group 3 
compatibility, some historic TIFF-F readers have not been able to 
read such files. The minimum subset of TIFF-F REQUIRES support for 
one-dimensional (Modified Huffman) files, so this choice maximizes 
portability. However, implementors seeking greater efficiency SHOULD 
use T.6 MMR compression when writing TIFF-F files. Some TIFF-F 
readers will also support two-dimensional Modified READ files. 
Implementors who wish to have the maximum flexibility in reading 
TIFF-F files should support all three of these compression methods 
(MH, MR, and MMR). 


Almost all facsimile products support both standard (98 dpi) vertical 
resolution and "fine" (196 dpi) resolution. Therefore, fine- 
resolution files are quite portable in the real world. 


In 1993, the ITU-T added support for higher resolutions in the T.30 
recommendation, including 200 x 200, 300 x 300, and 400 x 400 in dots 
per inch-based units. At the same time, support was added for metric 
dimensions equivalent to the following inch-based resolutions: 39lv x 
204h and 391v x 408h. Therefore, the full set of inch-based 
equivalents of the new resolutions are supported in the TIFF-F 
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writer, as they may appear in some image-data streams received from 
Group 3 facsimile devices. However, many facsimile terminals and 
older versions of TIFF-F readers are likely not to support these 
higher resolutions. 


Per [T.4], it is permissible for applications to treat the following 
XResolution values as equivalent: <204,200> and <400,408>. 
Similarly, the following YResolution values may also be treated as 
equivalent: <98, 100>, <196, 200>, and <391, 400>. These 
equivalencies were allowed by [T.4] to permit conversions between 
inch- and metric-based facsimile terminals. 


The optional support of metric-based resolutions in the TIFF-F reader 
(i.e., 77 x 38.5 cm) is included for completeness, as they are used 
in some legacy TIFF-F applications, but this use is not recommended 
for the creation of TIFF-F files by a writer. 


4.5.3. EOL byte-aligned 


The historical convention for TIFF-F has been that all EOLs in 
Modified Huffman or Modified READ data must be byte-aligned. 
However, Baseline TIFF has permitted use of non byte-aligned EOLs by 
default, so that a large percentage of TIFF-F reader implementations 
support both conventions. Therefore, the minimum subset of TIFF-F, 
or Profile S, as defined in Section 3, includes support for both 
byte-aligned and non-byte-aligned EOLs; see Section 3.2.2. 


An EOL is said to be byte-aligned when Fill bits have been added as 
necessary before EOL codes so that EOL always ends on a byte 
boundary, thus ensuring an EOL sequence of a one byte preceded by a 
zero nibble: xxxx0000 00000001. 


Modified Huffman compression encodes bits, not bytes. This means 
that the end-of-line token may end in the middle of a byte. In byte 
alignment, extra zero bits (Fill) are added so that the first bit of 
data following an EOL begins on a byte boundary. In effect, byte 
alignment relieves application software of the burden of bit-shifting 
every byte while parsing scan-lines for line-oriented image 
manipulation (such as writing a TIFF file). 


For Modified READ compression, each line is terminated by an EOL and 
a one-bit tag bit. Per [T.4], the value of the tag bit is 0 if the 
next line contains two-dimensional data and 1 if the next line is a 
reference line. To maintain byte alignment, fill bits are added 
before the EOL/tag bit sequence so that the first bit of data 
following an MR tag bit begins on a byte boundary. 
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4.5.4. EOL 


As illustrated in FIGURE 1/T.4 in [T.4], MH-encoded facsimile 
documents begin with an EOL, which in TIFF-F may be byte-aligned. 
The last line of the image is not terminated by an EOL. Similarly, 
respect, images encoded with Modified READ two-dimensional 
compression begin with an EOL, followed by a tag bit. 


4.5.5. RTC Exclusion 


Aside from EOLs, TIFF-F files have historically only contained image 
data. This means that applications seeking to maintain strict 
conformance with the rules in [TIFF] and compatibility with 
historical TIFF-F SHOULD NOT include the Return To Control sequence 
(RTC) (consisting of 6 consecutive EOLs) when writing TIFF-F files. 
However, applications intended to support "transparency" of [T.4] 
image data MAY include RTCs if the flag settings of the T4Options 
field are set for non byte aligned MH or MR image data. Implementors 
of TIFF readers should also be aware that there are some existing 
TIFF-F implementations that include the RTC sequence in MH/MR image 
data. Therefore, TIFF-F readers MUST be able to process files that 
do not include RTCs and SHOULD be able to process files that do 
include RTCs. 


4.5.6. Use of EOFB for T.6 Compressed Images 


TIFF-F pages encoded with the T.6 Modified Modified READ compression 
method MUST include an "end-of-facsimile-block" (EOFB) code at the 
end of each coded strip. Per [TIFF], the EOFB code is followed by 
pad bits as needed to align on a byte boundary. TIFF readers SHOULD 
ignore any bits other than pad bits beyond the EOFB. 


4.6. Example Use of TIFF-F 


The Profile F of TIFF (i.e., TIFF-F content) is a secondary component 
of the VPIM Message, as defined in [VPIM 2]. Voice messaging systems 
can often handle fax store-and-forward capabilities in addition to 
traditional voice message store-and-forward functions. As a result, 
TIFF-F fax messages can optionally be sent between compliant VPIM 
systems and may be rejected if the recipient system cannot deal with 
fax. 


Refer to the VPIM Specification for proper usage of this content. 
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4.7. Profile F: Extended Black-and-white Fax Profile Summary 
Recommended fields are shown with an asterisk (*). 


Required fields or values are shown with a double asterisk (**). If 
the double asterisk is on the field name, then all the listed values 
are required of implementations; if the double asterisks are in the 

Values column, then only the values suffixed with a double asterisk 

are required of implementations. 


A A E D E e SSeS A E sees + 
| Baseline Fields | Values 
A pa O So e A A tn + 
| BitsPerSample | 1** 
AO A S E Hesse sire eS Sse SSS n + 

Compression 3**: 1D Modified Huffman and 

2D Modified READ coding 
| | 4: 2D Modified Modified READ | 
| | coding | 
A A + 
| DateTime* | (ASCII): date/time in 24-hour | 
| | format "YYYY:MM:DD HH:MM:SS" | 
Peo See eee EE eo Sst Ses SSeS ae + 
| FilloOrder** | 1: most significant bit first | 
| 


2: least significant bit first | 


{ASCII}: A string describing | 
the contents of the image. 


| 

| 
toss = AZ O AA + 
| ImageWidth | 1728**, 2048, 2432, 2592, 
| | 3072, 3456, 3648, 4096, 4864 | 
AZ O AZ O E A E S + 
| ImageLength** | n: total number of scanlines | 
| | in image | 
a SE A AZ O A E + 
| NewSubFileType | 2**: Bit 1 identifies single | 
| | page of a multi-page document | 
AZ O AZ a + 
| Orientation | 1**-8, Default 1 
AZ O AZ O O E + 
| PhotometricInterpretation | 0: pixel value 1 means black | 
| *x* | 1: pixel value 1 means white | 
AO = S aar e O E E EEE T + 
| ResolutionUnit** | 2: inch 
| | 3: centimeter | 
Fn a + 
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+ See et eer ee ee ee ee er ee ree 
| RowsPerStrip** 


+ =-= — COIN III 
| SamplesPerPixel 


+ ——— _ _ ——__evmmnxojííí  _— —— 
| Software* 


| StripOffsets** 


+ a E al sepa a. ask aime as Seg ae at say apes gee as Ste mn) sca ar aa aon meg ol 
XResolution 


+ A as Se a O A iat me, Set Nh Se eS a paia 
| YResolution 
+ A A A ee ee 


| Extension Fields 


T40ptions 


| T40ptions (continued) 


+ A ey A E AS eS 
| T6Options 


| PageNumber** 


+ e ii E 


et al. 
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+ —— + —— + —— + — + ——+ 


+ + —— + — H 4+ 


n: number of scanlines per 
TIFF strip 


{ASCII}: name & release 
number of creator software 


<n>: number or bytes in TIFF 


<n>: offset from beginning of 
file to each TIFF strip 


200, 204**, 300, 400, 408 
(written in pixels/inch) 


98**, 196**, 100, 
200, 300, 391, 400 
(written in pixels/inch) 


0**: required if Compression 
is Modified Huffman, EOLs are 
not byte aligned 

1: required if Compression is 
2D Modified READ, EOLs are 
not byte aligned 

4**: required if Compression 
is Modified Huffman, EOLs are 
byte aligned 


5: required if Compression 
is 2D Modified READ, EOLs are 
byte aligned 


0: required if Compression is 
2D Modified Modified READ 


{ASCII}: 
document 


name of scanned 


n,m: page number followed by 
total page count 


Standards Track 


February 2005 


-+ 


-+ 


-+ 


-+ 


-+ 


-+ 


-+ 


-+ 
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$ O O O O O HS 8 SS SSS sa eS Ss eS + 
| New Fields | 
AO O O O O O PO O O O O O O + 
| BadFaxLines* | number of "bad" scanlines 
| | encountered during reception | 
$ r O O O E E E S O O E EE + 
| CleanFaxData* | 0: no "bad" lines 
| | 1: "bad" lines exist, but were | 
regenerated by receiver 
2: "bad" lines exist, but have 
| | not been regenerated | 
a ee ee feat + 
| ConsecutiveBadFaxLines* | Max number of consecutive | 
| | "bad" lines received | 
A a ee eee ho SS Se Se eee + 
| GlobalParametersIFD* | IFD: global parameters IFD 
t-------- 3-5 E $ O O O O O O + 
| ProfileType* | n: type of data stored in file | 
PO O O O O PA O O O O T A + 
| FaxProfile* | n: ITU-compatible fax profile | 
$ O O O O O $ O O O O O EE + 
CodingMethods* n: compression algorithms used 
in file 
FS SR SS RS SR PO O O O O + 


5. Profile J: Lossless JBIG Black-and-White Fax profile 


This section defines the lossless JBIG black-and-white profile of 
TIFF for facsimile, designated Profile J. Implementations of this 
profile are required to implement Profile S as well. 


The previous section described the extended interchange set of TIFF 
fields for black-and-white fax, which provided support for the MH, 
MR, and MMR compression of black-and-white images. This section adds 
a profile with JBIG compression capability. 


5.1. Overview 


This section describes a black-and-white profile that uses JBIG 
compression. The ITU-T has approved the single-progression 
sequential mode of JBIG [T.82] for Group 3 facsimile. JBIG coding 
offers improved compression for halftoned originals. JBIG 
compression is used in accordance with the application rules given in 
ITU-T Rec. T.85 [T.85]. 


This profile is essentially the extended black-and-white profile with 
JBIG compression used instead of MH, MR, or MMR. 
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5.2. Required TIFF Fields 


This section lists the required fields and the values they must have 
to be ITU-compatible. Besides the fields listed in Section 2.2.1, 
the extended black-and-white fax profile requires the following 
fields. 


5.2.1. Baseline fields 


The TIFF fields that SHALL be used in this profile are the same as 
those described in Section 4.2.1 for the extended black-and-white 
profile, with two exceptions: the following text replaces the text in 
Section 4.2.1 for the Compression and FillOrder fields. 


Compression(259) = 9. 
SHORT 
RequiredByTIFFBaseline 
9 = JBIG coding. This is a TIFF extension value. 
Default = 1 (and is not applicable; field must be specified). 
Profile J uses ITU-T T.85 profile of T.82; see T820ptions field. 


FillOrder(266) = 1, 2. 

SHORT 
RequiredByTIFFBaseline 
1 = Pixels are arranged within a byte such that pixels with lower 
values are stored in the higher-order bits of the byte, i.e., most 
significant bit first (MSB). 
2 = Pixels are arranged within a byte such that pixels with lower 
column values are stored in the lower-order bits of the bytes, 
i.e., least significant bit first (LSB). 
Profile J readers must be able to read data in both bit orders. 


5.2.2. Extension fields 
Same fields as those in Section 2.2.1. 


5.2.3. New fields 


T820ptions (435) = 0 
LONG 
Required when Compression = 9 


Individual bits are set to indicate the applicable profile of JBIG 
coding; all bits set to 0 indicates ITU-T T.85 profile of T.82; 
Other values are for further study. 

Default is all bits 0, and field may be omitted if this is the 
value. (Field may be omitted in Profile J files.) 
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Note: A T.82 decoder can decode a T.85-encoded image when it handles 
the NEWLE marker code as described Corrigendum 1 in [T.85]. 

5.3. Recommended TIFF Fields 
See Sections 2.2.3 and 2.2.4. 

5.4. Profile J: Lossless JBIG Black-and-white Fax Profile Summary 
Recommended fields are shown with an asterisk (*). 

Required fields or values are shown with a double asterisk (**). If 
the double asterisk is on the field name, then all the listed values 
are required of implementations; if the double asterisks are in the 


Values column, then only the values suffixed with a double asterisk 
are required of implementations. 


AO = AZ O E + 
| Baseline Fields | Values 
iii o Ss SS E + 
| BitsPerSample | 1** 
AO = AZ O T A E + 
| Compression | 9**: JBIG coding 
AZ = AZ O O + 
| DateTime* | (ASCII): date/time in 24-hour | 
| | format "YYYY:MM:DD HH:MM:SS" | 
a A ei ae ea ec Pasos SSeS Ses 8 ss SSS Saas ees ane + 
FillOrder** 1: most significant bit first 
2: least significant bit first 
toss O AZ O O + 
| ImageDescription* | {ASCII}: A string describing 
| | the contents of the image | 
AO ES AZ O O + 
ImageWidth 1728**, 2048, 2432, 2592, 
3072, 3456, 3648, 4096, 4864 
AO = E eee eee + 
| ImageLength** | n: total number of scanlines | 
| | in image | 
AZ O AZ O O A E S + 
NewSubFileType** 2: Bit 1 identifies single 
page of a multi-page document 
AO = Pas SS Ss 2222239222232 SS SS + 
| Orientation | 1**-8, Default 1 
AO O A O O + 
| PhotometricInterpretation | 0: pixel value 1 means black | 
| aoe | 1: pixel value 1 means white | 
AO O aa + 
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+ A ay en a A ae ero 


+ SSS SS Se a ee A 


+ el Se ee 


+ A A ey A a A ra re 


+ AS A SS A A 


+ e A oe A A o o A O E a E E 


+ A A A AE 


ResolutionUnit** 


RowsPerStrip** 


SamplesPerPixel** 


Software* 


StripByteCounts** 


StripOffsets** 


XResolution 


YResolution 


File Format for Internet Fax 


+ —— + —— + — + —— + ——+ 


+ —— + 


4+--------------------------- + 


+ Se Sa Se eer A ee 


+ a see a AA A ae es A eee ee 


+ SoS Sf SSeS See Se Se See ee 


+ O A gg aes pony es og es Mey ak eg ee ee Se ee any ee ny 
GlobalParametersIFD* 
+ al a SG al Sera lg aoe apne eres Sag omy at aes ls es pepe Seay ol ald me ag eh we 


+ A A AA ee ee A ree 


+ Er a a A A a E a A A A a 


+ HA e A O a ee ee e A ey 


+ tS SS he eS AN A a 


Buckley, 


Extension Fields 


Document Name* 


PageNumber** 


New Fields 


T820ptions** 


ProfileType* 


FaxProfile* 


CodingMethods* 


et al. 


+ 


+ —— + 


+ —— + — +— +—+—+ 
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A A + O Pe e e a + 
2: inch | 
3: centimeter | 

a i e ne q a a LS pa o SY es Sa a fs NaS Ft q a + 
n: number of scanlines per | 
TIFF strip | 

A E ee EE + 
1 | 

A EE A A ee ee ee + 
{ASCII}: name & release | 
number of creator software | 

AAA A AA AA A H AS ey ee en + 
<n>: number of bytes in TIFF | 
strip | 

SSS SSS SS SS SS SS SSS E SS Se SO ee + 
<n>: offset from beginning of 
file to each TIFF strip 

eS eS ee A A A + 
200, 204**, 300, 400, 408 | 
(written in pixels/inch) | 

E E e eg a a A a A Nd gb eps + 
98**, 196**, 100, 

200, 300, 391, 400 
(written in pixels/inch) | 

A AAA REEE RDA + 

A nena ener l 
{ASCII}: name of document 

scanned 

T A sa E a a ai Ft ae a at pl eS a Fe Se i AA Sd + 
n,m: page number followed by | 
total page count | 

EEE O EEEE + 

A : 
IFD: global parameters IFD | 

SS A ee Se SS a SS Se es + 
0: T.85 profile of T.82 | 

AA A A A A ae AR A te te + 
n: type of data stored in file | 

A a a E e sn ae pe Se Fg e pa a Sy es E i fae Se + 
n: ITU-compatible fax profile | 

a a Ad gh a ce as a A et a AN + 
n: compression algorithms used | 
in file | 

vA ee a A A A a A A + 
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6. Profile C: Base Color Fax profile 
6.1. Overview 


This section defines the lossy color profile of TIFF for facsimile, 
designated Profile C. Implementations of this profile are required 
to also implement Profile S as well. 


This is the base profile for color and grayscale facsimile, which 
means that all applications that support color fax must support this 
profile. The basic approach is the lossy JPEG compression [T.4, 
Annex E; T.81] of L*a*b* color data [T.42]. Grayscale applications 
use the L* lightness component; color applications use the L*, a* and 
b* components. 


This profile uses a new PhotometricInterpretation field value to 
describe the L*a*b* encoding specified in [T.42]. This encoding 
differs in two ways from the other L*a*b* encodings used in TIFF 
[TIFF, TIN1]: it specifies a different default range for the a* and 
b* components, based on a comprehensive evaluation of existing 
hardcopy output, and it optionally allows selectable range for the 
L*, a* and b* components. 


6.2. Required TIFF Fields 


This section lists the required fields, in addition to those given in 
Section 2.2.1, and the values they must support to be compatible with 
ITU-T Rec. T.42 and Annex E in ITU-T Rec. T.4. 


6.2.1. Baseline Fields 


ImageWidth (256). 

SHORT or LONG 
This profile supports the following fixed page widths: 864, 1024, 
1216, 1728, 2048, 2432, 2592, 3072, 3456, 3648, 4096, 4864. 


NewSubFileType (254) = (Bit 1=1). 

LONG 
RequiredByTIFFforFAX 
Bit 1 is 1 if the image is a single page of a multi-page document. 
Default = 0 (no subfile bits on, so may not be omitted for fax). 


BitsPerSample(258) = 8. 
SHORT 
Count = SamplesPerPixel 
The base color fax profile requires 8 bits per sample. 
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Compression(259) = 7. 

SHORT 
Base color fax profile uses Baseline JPEG compression. Value 7 
represents JPEG compression as specified in [TTN2]. 


FillOrder(266) = 1 , 2. 
SHORT 
RequiredByTIFFBaseline 
Profile C readers must be able to read data in both bit orders, 
but the vast majority of facsimile products store data LSB first, 
exactly as it appears on the telephone line. 
1 = Most Significant Bit first. 
2 Least Significant Bit first. 


PhotometricInterpretation(262) = 10. 

SHORT 
Base color fax profile requires pixel values to be stored with the 
CIE L*a*b* encoding defined in ITU-T Rec. T.42. This encoding is 
indicated by the PhotometricInterpretation value 10, referred to 
as ITULAB. With this encoding, the minimum sample value is 
mapped to 0, and the maximum sample value is mapped to (2%n - 1), 
i.e., the maximum value, where n is the BitsPerSample value. The 
conversion from unsigned ITULAB-encoded samples values to signed 
CIE L*a*b* values is determined by the Decode field; see Section 
¡AT 


NOTE: PhotometricInterpretation values 8 and 9 specify encodings for 
use with 8-bit-per-sample CIE L*a*b* [TIFF] and ICC L*a*b* [TIN1] 
data, but they are fixed encodings, which use different minimum and 
maximum samples than the T.42 default encoding. As currently 
defined, they are not able to represent fax-encoded L*a*b* data. 


ResolutionUnit (296) = 2. 

SHORT 
The unit of measure for resolution. 2 = inch. 
ITU-T standards only specify inch-based resolutions for color fax. 
Default = 2 (field may be omitted if this is the value). 


SamplesPerPixel (277) = 1, 3. 

SHORT 
1: L* component only, required in base color profile 
3: L*, a*, b* components 
Encoded according to PhotometricInterpretation field 
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XResolution(282) = 100, 200, 300, 400. 

RATIONAL 

YResolution(283) = 100, 200, 300, 400. 

RATIONAL 
The resolution of the image is expressed in pixels per resolution 
unit. In pixels per inch, allowed XResolution values are 100, 


200, 300, and 400. The base color fax profile requires the pixels 
to be square, hence YResolution must equal XResolution. Base 
resolution is 200 pixels per inch and SHALL be supported by all 
implementations of this profile. 


NOTE: The functional equivalence of inch-based and metric-based 
resolutions is maintained, per Annex E.6.5 in [T.4]. See table in 
Section 2.2.2. 


NOTE: Not all combinations of XResolution, YResolution and ImageWidth 
are legal. The following table gives the legal combinations for 
inch-based resolutions and the corresponding paper sizes [T.30]. 


$ = += ==23 22223203 SS SS SSS == 22252 25232 SE == + 
| XResolution x YResolution | ImageWidth 
$ O A EE +--------------------------- + 
| 100 x 100 | 864 | 1024 | 1216 | 
+o SSR SSS Sea SS SS SS Se SSS PaaS eS SS SS Sa See ai + 
| 200 x 200 | 1728 | 2048 | 2432 | 
$==>5>==2=>= +22 285753555 FE=s=2=2>===p92292===+53=238=+== + 
| 300 x 300 | 2592 | 3072 | 3648 | 
ii aS cma PARRAS ES RS OR + 
| 400 x 400 | 3456 | 4096 | 4864 | 
$ O +--------------------------- + 
|Letter,A4| B4 | a3 | 
| Legal | | | 
$ O E E + 
| Paper Size | 
a ai paria ala + 


6.2.2. Extension Fields 


The JPEG compression standard allows for the a*b* chroma components 
of an image to be subsampled relative to the L* lightness component. 
The extension fields ChromaSubSampling and ChromaPositioning define 
the subsampling. They are the same as YCbCrSubSampling and 
YCbCrPositioning in [TIFF] but have been renamed to reflect their 
applicability to other color spaces. 
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6. 


2. 


ChromaSubSampling (530). 
SHORT 


Count = 2 

Specifies the subsampling factors for the chroma components of a 
L*a*b* image. The two subfields of this field, 
ChromaSubsampleHoriz and ChromaSubsampleVert, specify the 
horizontal and vertical subsampling factors respectively. 


SHORT 0: ChromaSubsampleHoriz = 1, 2. 
1: equal numbers of lightness and chroma samples horizontally, 
2: twice as many lightness samples as chroma samples horizontally, 


SHORT 1: ChromaSubsampleVert = 1, 2. 
1: equal numbers of lightness and chroma samples vertically, 
2: twice as many lightness samples as chroma samples vertically, 


The default value for ChromaSubSampling is (2,2), which is the 
default for chroma subsampling in color fax [T.4, Annex E]. No 
chroma subsampling, i.e., ChromaSubSampling = (1,1), is an option 
for color fax. 


ChromaPositioning(531) = 1. 
SHORT 


Specifies the spatial positioning of chroma components relative to 
the lightness component. 

1: centered, value of 1 means chrominance samples are spatially 
offset and centered with respect to luminance samples. See the 
current TIFF specification under YcbCr positioning for further 
information. 

Default = 1, which is what ITU-T T.4, Annex E specifies. 


3. New Fields 

Decode (433). 

SRATIONAL 
Count = 2 * SamplesPerPixel 
Describes how to map image sample values into the range of values 
appropriate for the current color space. In general, the values 
are taken in pairs and specify the minimum and maximum output 
value for each color component. For the base color fax profile, 


Decode has a count of 6 values and maps the unsigned ITULAB- 
encoded sample values (Lsample, asample, bsample) to signed L*a*b* 
values, as follows: 

L* = Decode[0] + Lsample x (Decode[1]-Decode[0])/(2%n -1) 

a* = Decode[2] + asample x (Decode[3]-Decode[2])/(2%n -1) 

b* = Decode[4] + bsample x (Decode[5]-Decode[4])/(2%n -1) 
where Decode[0], Decode[2] and Decode[4] are the minimum values 
for L*, a*, and b*; Decode[1], Decode[3] and Decode[5] are the 
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maximum values for L*, a*, and b*; and n is the BitsPerSample. 
When n=8,=20 L*=Decode[0] when Lsample=0 and L*=Decode[1] when 
Lsample=255. 


ITU-T Rec. T.42 specifies the ITULAB encoding in terms of a range and 
offset for each component, which are related to the minimum and 
maximum values as follows: 


minimum - (range x offset) / 2^n - 1 
maximum = minimum + range 


The Decode field default values depend on the color space. For the 
ITULAB color space encoding, the default values correspond to the 
base range and offset, as specified in ITU-T Rec. T.42 [T.42]. The 
following table gives the base range and offset values for 
BitsPerSample=8, and the corresponding default minimum and maximum 
default values for the Decode field, calculated using the equations 
above when PhotometricInterpetation=10. 


Refer to ITU-T Rec. T.42 [T.42] to calculate the range and offset, 
and hence the minimum and maximum values, for other BitsPerSample 


values. 
BO = 5 $= 5 == + 
| ITU-T Rec. T.42 | Decode | 
== 3222 tespo+s=>=5 | base values | default values 
| BitsPer. + ‘Component: +=====22+=2==H==== E + 
| -Sample | | Range | Offset | Min | Max 
+--------- +----------- +-------- +--------- +-------------- +------------- + 
| 8 | L* | 100 | 0 | 0 | 100 | 
| +----------- +-------- +--------- +-------------- +------------- + 
| | a* | 170 | 128 | -21760/255 | 21590/255 | 
| +----------—- +-------- +--------- +-------------- Ho + 
| | b* | 200 | 96 | -19200/255 | 31800/255 | 
+--------- +----------- +-------- +--------- +-------------- +------------- + 


For example, when PhotometricInterpretation=10 and BitsPerSample=8, 
the default value for Decode is (0, 100, -21760/255, 21590/255, 
-19200/255, 31800/255). For guidelines on the use of the Decode 
field, see section 5.2.2 of [GUIDE]. 


Buckley, et al. Standards Track [Page 51] 


RFC 3949 File Format for Internet Fax February 2005 


6.3. Recommended TIFF Fields 
See Sections 2.2.3. and 2.2.4. 

6.4. Profile C: Base Color Fax Profile Summary 
Recommended fields are shown with an asterisk (*). 
Required fields or values are shown with a double asterisk (**). If 
the double asterisk is on the field name, then all the listed values 
are required of implementations; if the double asterisk is in the 


Values column, then only the values suffixed with a double asterisk 
are required of implementations. 


sas cou cas O tan a + 
| Baseline Fields | Values 
$ E I EOE P aiei aS O + 
| BitsPerSample | 8**: 8 bits per color sample | 
AZ = AZ N A E A + 
| Compression** | 7: JPEG 
AZ = AZ O E ST + 
DateTime* {ASCII}: date/time in 24-hour 
format "YYYY:MM:DD HH:MM:SS" 
e A nS RCA Ra ET AZ O + 
| Fillorder** | 1: most significant bit first | 
| | 2: least significant bit first | 
HE A AS SE SAS AZ A r A + 
ImageDescription* {ASCII}: A string describing 
the contents of the image 
AZ = AZ E A + 
| ImageWidth | 864, 1024, 1216, 1728**, 2048 | 
| | 2432, 2592, 3072, 3456, 3648 | 
| | 4096, 4864 | 
AO AZ O T T + 
| ImageLength** | n: total number of scanlines | 
| | in image | 
AZ = esas Sa eS ee ee Sa + 
| NewSubFileType** | 2: Bit 1 identifies single page| 
| | of a multi-page document 
AZ = AZ N + 
| Orientation | 1**-8, Default 1 
A = AZ O + 
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A O O O a E E + 
| PhotometricInterpretation | 10**: ITULAB 
A $ O O O O E + 
| ResolutionUnit** | 2: inch 
dense ===: === == senseri SSS SS SSS 222235 25=5S + 
| RowsPerStrip** | n: number of scanlines per 
| | TIFF strip | 
AZ T E R AA sags oon E + 
SamplesPerPixel 1**: L* (lightness) 
3: LAB 
HS tac tm at a aa tes SoS see SSS >28+s>2 85285 + 
| Software* | {ASCII}: name & release number | 
| | of creator software | 
$ AA O O O + 
| StripByteCounts** | <n>: number or bytes in 
| | TIFF strip | 
Poe Sa ee AA oe ee besos E Seo see ee eee + 
| StripOffsets** | <n>: offset from beginning 
| | of file to each TIFF strip | 
O SSS Ss 5 5S—5 iii as + 
| XResolution | 100, 200**, 300, 400 (written | 
| | in pixels/inch) | 
$ O AA O O O E T + 
| YResolution | 100, 200**, 300, 400 
| | (must equal XResolution) | 
E E 8892 de 2 alata RS 55 + 
| Extension Fields | 
scion pit ia er a ia ee i a a or an a car am i + 
| DocumentName* | {ASCII}: name of scanned 
| | document | 
ta ii == SFE === E SS SSS SS SS SSeS == + 
| PageNumber** | n,m: page number followed by | 
| | total page count | 
AZ O AO O estae rx eR asta E a + 
| ChromaSubSampling | (1,1), (2, 2)** | 
| | (1, 1): equal numbers of | 
| | lightness and chroma samples | 
| | horizontally and vertically | 
| | (2, 2): twice as many lightness| 
samples as chroma samples 
horizontally and vertically 
e ia it HES SS == SS SPSS ito SSS sSSe ss + 
| ChromaPositioning | 1**: centered 
a ee SSeS a eS Se ee ao ae + 
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+ SS A ee ee Se Se ee eee 


New Fields 


+ 


+ HA ee 


Decode** 


+ SS SSS See Se ee ee ee ee E 


GlobalParametersIFD* 


ProfileType* 


+ A ae ee AAA A A A A A ere 


FaxProfile* 


+ 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
! 

+ — + —— + —— + —— + 


+ SSS A A A 


+ A A E ee 


+ A A ij A A A ri A lts 


CodingMethods* 


VersionYear* 


+ 
| 
+ 
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minL, maxL, mina, maxa, minb, | 
maxb: minimum and maximum | 


values for L*a*b* 


IFD: IFD containing 
global parameters 


--------- + 


--------- + 


n: type of data stored in | 


TIFF file 


n: ITU-compatible fax 


--------- + 
profile | 
--------- + 


n: compression algorithms 


used in file 


== + 


byte sequence: year of ITU std | 


Profile L: Lossless Color Profile 


== + 


This section defines the lossless color profile of TIFF for 


facsimile, 


Maka 


This profile, 


Overview 


designated Profile L. 
required to also implement Profiles S and C as well. 


specified in [T.43] and [T.4] Annex G, 


Implementations of this profile are 


uses JBIG to 


code three types of color and grayscale images losslessly: one bit 


per color CMY, CMYK, 
color image; 


and RGB images; a palettized (i.e., mapped) 
and continuous tone color and grayscale images. The 


last two are multi-level and use the L*a*b* encoding specified in 
[T..42]-, 


dde. 


While under development, 


T: 


Color Encoding 


ITU- 


T Rec. T.43 was called 


of its major additions was palettized color images. 


only allows RGB color maps, 


maps, using the encoding specified in ITU-T Rec. 


but ITU-T Rec. 


images are expressed with indices (bits per sample) 


less, 


T.Palette, as one 
Baseline TIFF 


T.43 requires L*a*b* color 
T.42. Palette color 


of 12 bits or 


or optionally 13 to 16 bits, per [T.43] and Annex G in [T.4]. 


Profile L files use the color table in the T.43 data stream rather 
than the TIFF ColorMap field. 
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Enabling T.43 color maps in TIFF requires the extension field 
Indexed, as defined in [TIN1], and the PhotometricInterpretation 
field value 10, as defined in Section 6.2.1. The following table 
shows the corresponding PhotometricInterpretation, SamplesPerPixel, 
BitsPerSample, and Indexed field values for the different T.43 image 


types. 
$------------- 5-5 oo + 
Image Type |PhotometricIn| Samples Bits Per Indexed 
-terpretation| Per Pixel Sample 

| ------------ +------------- +---------- +---------- +--------—- | 
| RGB | 2=RGB | 3 | i | 0 | 
$---- o + 
| CMY | 5=CMYK | 3 | 1 | 0 | 
+------------ +------------- +---------- +---------- +--------- + 
| CMYK | 5=CMYK ž f| 4 | Í | 0 | 
+------------ +------------- +---------- +---------- +--------- + 
| Palette | 10=ITULAB | 1 | n | 1 | 
+------------ +------------- +---------- +---------- +--------- + 
| Grayscale | 10=ITULAB | 1 |2-8, 9-12 | 0 
+------------ +------------- +---------- +---------- +--------- + 
| Color | 10=ITULAB | 3 |2-8, 9-12 | 0 | 
+------------ +------------- +---------- +---------- +--------- + 


7.1.2. JBIG Compression 


T.43 uses the single-progression sequential mode of JBIG, defined in 
ITU-T Rec. T.82. (Other compression methods are for further study.) 
To code multi-level images using JBIG, which is a bi-level 
compression method, an image is resolved into a set of bit-planes, 
and each bit-plane is then JBIG compressed. For continuous-tone 
color and grayscale images, Gray code conversion is used. The Gray 
code conversion is part of the data-stream encoding and is therefore 
invisible to TIFF. 


7.2. Required TIFF Fields 
This section lists the required fields, in addition to those in 


Section 2.2.1, and the values they must have to be compatible with 
ITU-T Rec. T.43. 
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7.2.1. Baseline Fields 


ImageWidth (256). 
SHORT or LONG 
Same page widths as the base color profile; see Section 6.2.1. 


NewSubFileType(254) = (Bit 1=1). 
LONG 
RequiredByTIFFforFAX 
Bit 1 is 1 if the image is a single page of a multi-page document. 
Default = 0 (no subfile bits on, so may not be omitted for fax). 
BitsPerSample(258) = 1, 2 - 8, 9 - 12. 
SHORT 
Count = SamplesPerPixel 
RGB, CMY, CMYK: 1 bit per sample 
Continuous tone (L*a*b*): 2 - 8 bits per sample, 9 - 12 bits 
optional. Palette color: 12 or fewer bits per sample. 


Note: More than 8 bits per sample is not baseline TIFF. 


Compression(259) = 10. 

SHORT 
10: ITU-T Rec. T.43 representation, using ITU-T Rec. T.82 (JBIG) 
coding 


FillOrder(266) =1, 2. 
SHORT 
RequiredByTIFFBaseline 
Profile L readers must be able to read data in both bit orders, 
but the vast majority of facsimile products store data LSB 
first, exactly as it appears on the telephone line. 
1 = Most Significant Bit first. 


2 = Least Significant Bit first. 
PhotometricInterpretation(262) = 2, 5, 10. 
SHORT 

2: RGB 
5: CMYK, including CMY 
10: ITULAB 


Image data may also be stored as palette-color images, where pixel 
values are represented by a single component that is an index into 
a color map using the ITULAB encoding. This color map is 
specified by the color palette table embedded in the image data 
stream. To use palette-color images, set the 
PhotometricInterpretation to 10, SamplesPerPixel to 1, Indexed to 
1, and use the color map in the data stream. See Section 7.1.1 
for discussion of the color encoding. 
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ResolutionUnit (296) = 2. 

SHORT 
The unit of measure for resolution. 2 = inch. 
ITU-T standards only specify inch-based resolutions for color fax. 
Default = 2 (field may be omitted if this is the value). 


SamplesPerPixel (277) = 1, 3, 4. 
SHORT 
1: Palette-color image, or L*-only if Indexed = 0 and 
PhotometricInterpretation is 10 (ITULAB). 
3: RGB, or L*a*b*, or CMY if PhotometricInterpretation is 5 


(CMYK). 
4: CMYK. 
XResolution (282) = 100, 200, 300, 400. 
RATIONAL 
YResolution (283) = 100, 200, 300, 400. 
RATIONAL 
The resolution of the image is expressed in pixels per resolution 
unit. In pixels per inch, allowed XResolution values are 100, 


200, 300, and 400. The lossless color fax profile requires the 
pixels to be square, hence YResolution must equal XResolution. 
Base resolution is 200 pixels per inch. 


.2.2. Extension Fields 


Indexed(346) = 0, 1. 

SHORT 
0: not a palette-color image. 
1: palette-color image. 
This field is used to indicate that each sample value is an index 
into an array of color values specified in the image data stream. 
Because the color map is embedded in the image data stream, the 
ColorMap field is not used in Profile L. Lossless color fax 
profile supports palette-color images with the ITULAB encoding. 
The SamplesPerPixel value must be 1. 


.2.3. New Fields 


Decode (433) 
SRATIONAL 
Decode is used in connection with the ITULAB encoding of image 


data; see Section 6.2.3. 


3. Recommended TIFF Fields 


See Sections 2.2.3. and 2.2.4. 
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Recommended fields are shown with an asterisk 


Required fields or values are shown 
the double asterisk is on the field 
are required of implementations; if 
Values column, then only the values 
are required of implementations. 
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Profile L: Lossless Color Fax Profile Summary 


(*). 


with a double asterisk If 
name, then all the listed values 
the double asterisks are in the 
suffixed with a double asterisk 


(**) A 


A AZ = + 
| Baseline Fields | Values 
A H d A = + 
| BitsPerSample | 1: Binary RGB, CMY (K) 
| | 8**: 8 bits per color sample 
| | 9 - 12: optional | 
$ AZ O = + 
| Compression | 10**: JBIG, per T.43 
AZ AZ O + 
| DateTime* | (ASCII): date/time in the 24-hour 
| | format "YYYY:MM:DD HH:MM:SS" 
$ AZ O A E RE + 
| FillOrder** | 1: Most significant bit first 
| | 2: Least significant bit first | 
$ AZ = + 
| ImageDescription* | (ASCII): A string describing the | 
| | contents of the image | 
A ae aR RRR RE AZ E A S + 
| ImageWidth | 864, 1024, 1216, 1728**, 2048, 2432, | 
| | 2592, 3072, 3456, 3648, 4096, 4864 | 
$ AZ O = + 
| ImageLength** | n: total number of scanlines in image | 
$ ASE AZ = + 
NewSubFileType 2**: Bit 1 identifies single page of 

a multi-page document 

$ E A = + 
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$ OO A o o ee eee eee eens + 
Orientation | 1**-8, Default 1 
PO O O AO O O O O O O O + 
PhotometricInter- | 2: RGB 
pretation | 5: CMYK 
| 10**: ITULAB | 
$ O O $ O O O E O O E + 
ResolutionUnit** | 2: inch 
$ O O $ O O O O O + 
RowsPerStrip** | n: number of scanlines per TIFF strip| 
PO O OO AO O O O O O O + 
SamplesPerPixel | 1**: L* (lightness) | 
3: LAB, RGB, CMY | 
4: CMYK | 
$ pS Ss SE O SS E + 
Software* {ASCII}: name & release number of 
creator software 
$ O $ O O O O O O RE + 
StripByteCounts** | <n>: number or bytes in TIFF strip | 
$ OO O AO O O O O O O O + 
StripOffsets** | <n>: offset from beginning of file to] 
| each TIFF strip | 
PO O O ES SSS SS eS SaaS + 
XResolution | 100, 200**, 300, 400 (pixels/inch) 
PO O $ O O O O O a a a + 
YResolution equal to XResolution (pixels must be | 
square) | 
AO O O E E E T T + 
Extension Fields | 
$ RAER AO O O O O O O O A + 
DocumentName* | {ASCII}: name of scanned document | 
$ O O $ O O O O O O + 
PageNumber** | n,m: page number followed by total 
| page count | 
AO OO A O O O O O + 
Indexed | 0: not a palette-color image 
| 1: palette-color image | 
$ O O HSA A SR E + 
New Fields | 
$ O A O O O O O A 
Decode | minL, maxL, mina, maxa, minb, maxb: 
| minimum and maximum values for L*a*b*| 
+-------------------- $ O O O O O O O O + 
GlobalParameters | IFD: global parameters IFD | 
IFD* | | 
——— _ — —  — e — _ _ _  — — —_..o __ _ _ _ _ _ a —_  _  _ _— _Ñ—_ ___—_——_———c—c co — co —— —— —— —— —— —— + 
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+-------------------- $ + 
| ProfileType* | n: type of data stored in TIFF file | 
4+-------------------- $ + 
| FaxProfile* | n: ITU-compatible fax profile 
$ oo $ + 
| CodingMethods* | n: compression algorithms used in | 
| file | 
+-------------------- $ + 
| VersionYear* | byte sequence: year of ITU fax std 
+-------------------- $ + 


8. Profile M: Mixed Raster Content Profile 


This section defines the Mixed Raster Content profile of TIFF for 
facsimile, designated Profile M. Implementations of this profile are 
required to implement Profiles S and C and may optionally implement 
Profiles F, J and L. 


8.1. Overview 


Unlike previous fax profiles, which use a single coding method and 
resolution for an entire fax page, Mixed Raster Content [T.44] 
enables different coding methods and resolutions within a single 
page. For example, consider a page that contains black-and-white 
text, which is best coded with MMR or JBIG; a color bar chart, best 
coded with JBIG; and a scanned color image, best coded with JPEG. 
Similarly, although spatial resolution of 400 pixels per inch may be 
best for the black-and-white text, 200 pixels per inch is usually 
sufficient for a color image. 


Rather than applying one coding method and resolution to all 
elements, MRC allows multiple coders and resolutions within a page. 
By itself, MRC does not define any new coding methods or resolutions. 
Instead it defines a 3-layer image model for structuring and 
combining the scanned image data. The MRC 3-layer model has been 
applied here with the TIFF format to yield a data structure that 
differs from [T.44], though it applies the same coding methods, uses 
the same compressed image data streams, and is consistent with the 
TIFF principle of a single IFD per image. 


8.1.1. MRC 3-layer model 


The 3 layers of the MRC model are Foreground and Background, which 
are both multi-level, and Mask, which is bi-level. Each layer may 
appear only once on a page and is coded independently of the other 
two layers. The final image is obtained by using the Mask layer to 
determine whether output pixels come from the Foreground layer or the 
Background layer. When the Mask layer pixel value is 1, the 
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corresponding pixel from the Foreground layer is selected; when it is 
0, the corresponding pixel from the Background layer is selected. 
Details are given in the Introduction of [T.44]. 


In our earlier example, the shape of the black-and-white text and the 
mask for the color chart could be in the Mask layer, the color of the 
chart and text in the Foreground layer, and the color image in the 
Background layer. If a Mask layer pixel has a value of 1, the final 
image pixel will be, depending on the pixel location, from either the 
color chart or text color in the Foreground layer. If a Mask layer 
pixel has a value of 0, the final image pixel will be from the color 
image in the Background layer. 


Each layer is an image and, when present, is represented by at least 
one IFD in a TIFF file. This is consistent with TIFF, which provides 
fields to define the attributes, such as resolution, image size, bits 
per sample, etc., of a single image or layer. The distribution of 
content among layers is determined by the writer, as is the choice of 
coding method, color encoding, and spatial resolution for a layer. 


Not all pages, and not all parts of a page, require 3 layers. Ifa 
page has of only one layer, then that layer is the primary image 
whether it is a Background, Mask, or Foreground layer. If there is 
more than one layer, then the Mask must be one of the layers, in 
which case it is the primary image. In all cases, the primary image 
must be page size. 


MRC [T.44] allows a page to be transmitted as a series of stripes, 
each consisting of 1, 2 or 3 layers. The number of scanlines in each 
stripe can vary over the page. Although [T.44] does not allow 
overlap between images of a single layer, the MRC profile permits 
overlapping IFDs when one of the IFDs is used only to define a 
default image color. According to [T.4] Annex H, stripes having more 
than 1 layer SHOULD NOT be more than 256 lines in length unless the 
capability to receive longer stripes has been negotiated. 


Furthermore, color fax also requires the spatial resolutions of 
Background and Foreground images to be legal fax values that are also 
integer factors of the Mask image resolution. For example, if the 
Mask-Layer resolution is 400 pixels per inch, then allowable 
resolutions for the Foreground and Background layers are 100, 200, or 
400 pixels per inch; if the Mask is at 300 pixels per inch, then 
allowable values are 100 and 300. The Foreground and Background 
layer resolutions can be set independently of each other. 
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8.1.2. A TIFF Representation for the MRC 3-layer model 


In the TIFF representation of the 3-layer MRC model, each page is 
represented by a single IFD, called the Primary IFD. The nextIFD 
offset associated with a Primary IFD will point to the Primary IFD of 
the next page. If the page consists of a single layer, then the 
Primary IFD represents that layer. If more than one layer is 
present, the Primary IFD represents the Mask layer and the other 
layers are represented by a set of child IFDs that are referenced 
through the SubIFD extension field [TIN1] of the Primary IFD. To 
distinguish MRC-specific SubIFDs from other SubIFDs, the 
NewSubFileType field MUST have Bit 4 ON, indicating an MRC-related 
IFD. A new ImageLayer field is also introduced that consists of two 
values that identify the layer (Foreground, Background, or Mask) and 
the order within the layer (first, second, ... image of the layer); 
see Section 8.2.3. 


In Profile M, the Primary IFD represents a complete layer and 
corresponds to the primary image described in Section 8.1.1. There 
must be no other MRC-related IFDs or SubIFDs that contain image data 
corresponding to the layer represented by the Primary IFD. 


MRC [T.44] allows a page to be transmitted as a series of stripes. A 
strip within an IFD in a Profile M file represents a stripe ina 
[T.44] data stream. The [T.44] stripes of the Primary image are 
represented by a single, multiple-strip IFD; the [T.44] stripes of 
other layers are represented as multiple, single-strip IFDs. 


The layer represented by the Primary IFD may consist of strips of 
image data, but all the strips must be part of the single Primary 
IFD. For example, if the page consisted of only the Background 
layer, then all strips associated with the Background layer must be 
treated as a single image. Because MRC allows stripes with variable 
numbers of scanlines, a reader MUST support StripRowCounts field, as 
a writer may use it in place of the RowsPerStrip field to support a 
variable number of scanlines in each strip of the Primary IFD. In 
accordance with [TIN2], each strip shall be independently encoded, 
but coding parameters may not change between strips. 


Layers other than the layer represented by the Primary IFD store each 
strip as a separate IFD, allowing the coding parameters to change 
from strip to strip as described by the MRC standard [T.44]. In all 
cases, if the Mask layer exists, it shall be represented by a single 
IFD and a single set of coding parameters. 


The use of SubIFDs to store child IFDs is described in [TTN1]. When 


the Mask is the primary image, the Background and Foreground layer 
images are represented with child IFDs referenced by the SubIFDs 


Buckley, et al. Standards Track [Page 62] 


RFC 3949 File Format for Internet Fax 


February 2005 


field in the Primary IFD. There are multiple ways to organize the 
images of the Background and Foreground layer images: (1) the SubIFD 
field of the Primary IFD is an array of pointers to all child image 
IFDs, one entry per child image; (2) the SubIFD field is a single 
pointer to a linked list of all child image IFDs; (3) the SubIFD 
field is an array of two pointers, where the first pointer is toa 
linked list of all Background layer image IFDs, and the second 
pointer is to a linked list of all Foreground layer image IFDs. A 
Profile M writer SHOULD structure the Background and Foreground layer 
images by using (3), as shown in the example below. Furthermore, the 
child IFDs representing the images of the Background and Foreground 
layers SHOULD be ordered in the file in the same order as they occur 
on the page. However, a Profile M reader must scan all available 
child IFDs to locate and identify IFDs associated with MRC layers. 


(nextIFD) 
PRIMARY IFD PAGE 0 ----------------------- > PRIMARY IFD PAGE 1--> 
ImageLayer = [2,1] 
NewSubFileType = 18 
SubIFD[0] ------------------- SubIFD[1] 
V V 
Child IFD Child IFD 
ImageLayer = [1,1] ImageLayer [3,1] 


NewSubFileType = 16 


NewSubFileType 16 


| (next IFD) | (next IFD) 
V V 

Child IFD Child IFD 
ImageLayer = [1,2] ImageLayer [3,2] 


NewSubFileType = 16 


NewSubFileType 16 


| (next IFD) | (next IFD) 
V V 

Child IFD Child IFD 
ImageLayer = [1,3] ImageLayer [3,3] 


NewSubFileType = 16 


| (next IFD) 
V 
0 


NewSubFileType 16 


| (next IFD) 
v 
0 
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The XPosition and YPosition TIFF fields specify the offset to the 
upper left corner of the IFD in resolution units, which are inches in 
Profile M; see Section 8.2.2. The Primary IFD must not use XPosition 
or YPosition fields. 
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MRC [T.44] allows the specification of a default image color that is 
to be applied in the event no image data is transmitted for a given 
stripe and layer. The new field ImageBaseColor is used to store 
default image color specifications in Profile M, see 8.2.3. By 
setting the StripByteCounts array to zero values, an IFD defining a 
default color but containing no encoded image data can be specified. 
ImageBaseColor can also be used in IFDs that contain encoded image 
data. In that case, the fields of the IFD must accurately reflect 
the encoding of the image data. If the StripByteCount entry for a 


given strip is 0, then the ImageBaseColor is used for that strip. If 
the encoded image data is ITU L*a*b, the ImageBaseColor is 
interpreted with the encoding parameters of the image data. If the 


image data is not ITU L*a*b*, the ImageBaseColor is interpreted as 
8-bit ITU L*a*b*; see Section 8.2.3. 


8.2. Required TIFF Fields 


This section describes the TIFF fields required, in addition to those 
in Section 2.2.1, to represent MRC fax images. Since MRC stores fax 
data as a collection of images corresponding to layers or parts of 
layers, the coding methods, color encodings, and spatial resolutions 
used by previous profiles apply to Profile M. Therefore, the 
descriptions here will typically reference the appropriate earlier 
sections. Fields and values specific to Profile M are pointed out. 


8.2.1. Baseline Fields 


ImageWidth (256). 

SHORT or LONG 
Same page widths as Profile C, the base color profile; see Section 
6.2.1. In Profile M, the width of a Foreground or Background 
image in the coded data stream may be less than the page width, 
unless the Background or Foreground is the primary image, in which 
Case the width of the coded data stream is the page width. The 
ImageWidth field will always store the actual width of the coded 
data. 


NewSubFileType (254) = 16, 18. 

LONG 
For Profile M, the NewSubFileType field has two bits that are 
required. Bit 1 indicates a single page of a multi-page document 
and must be set for the Primary IFD; Bit 4 indicates the MRC 
imaging model as described in ITU-T Recommendation T.44 [T.44] and 
must be set for Primary IFDs and all MRC-specific child IFDs. 
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BitsPerSample(258) = 1, 2-8, 9-12 
SHORT 
SamplesPerPixel (277) = 1, 3, 4. 
SHORT 
Compression(259) = 1, 3, 4, 7, 9, 10. 
SHORT 
For Mask layer, see Sections 4.2.1 and 5.2.1. For Foreground and 


Background layers, see Sections 6.2.1 and 7.2.1 Compression=1 is 
not used by previous profiles. An IFD used only to specify the 
default image color for a layer and strip will not have any 
encoded image data associated with it, i.e., the StripByteCounts 
field will contain a 0. Since no image data exists in the IFD, 
the Compression field shall be set to 1, indicating no 
compression. A Compression field value of 1 is not allowed for 
any other IFDs. 


FillOrder(266) =1, 2. 
SHORT 
RequiredByTIFFBaseline 
Profile M readers must be able to read data in both bit orders, 
but the vast majority of facsimile products store data LSB first, 
exactly as it appears on the telephone line 
1 = Most Significant Bit first. 
2 = Least Significant Bit first. 


PhotometricInterpretation(262) = 0, 2, 10. 
SHORT 
For Mask layer, 0. For Foreground and Background layers, see 


Sections 6.2.1 and 7.2.1. 


ResolutionUnit (296) = 2. 

SHORT 
The unit of measure for resolution. 2 = inch. 
ITU-T standards only specify inch-based resolutions for color fax 
Default = 2 (field may be omitted if this is the value). 


StripByteCounts (279) 

SHORT or LONG 
In Profile M, it is permissible for the StripByteCounts value for 
a given strip to have a zero entry. This means there is no 
encoded image data corresponding to that strip. Instead, the 
current default image color should be used for the strip. The 
standard default image colors are black for the Foreground layer 
and White for the Background layer. The ImageBaseColor field can 
be used to specify other default colors; see Section 8.2.3. 
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XResolution(282) = 100, 200, 300, 400. 

RATIONAL 

YResolution(283) = 100, 200, 300, 400. 

RATIONAL 
The resolution of the image is expressed in pixels per resolution 
unit. In pixels per inch, allowed XResolution values for all 


layers are 100, 200, 300, and 400. Color fax requires the pixels 
to be square, hence YResolution must equal XResolution for all 
layers. The resolution of Background and Foreground layers must 
each be an integer factor of the Primary image, which is the Mask 
layer, when it is present; see Section 8.4. 


.2. Extension Fields 


ChromaSubSampling(530). 
SHORT 
ChromaPositioning(531). 
SHORT 
For Foreground and Background layers, see Section 6.2.2. 


Indexed(346) = 0, 1. 

SHORT 
For Foreground and Background layers: 1 indicates a palette-color 
image; see Section 7.2.2. 


T40ptions(292) = 0, 1, 4, 5. 
SHORT 

T60ptions (293) = 0. 

SHORT 


For Mask layer, see Section 4.2.2. 


SubIFDs (330). 

IFD 
Count = number of child IFDs. Each value is an offset from the 
beginning of the TIFF file to a child IFD [TIN1]. 


XPosition (286). 

RATIONAL 

YPosition (287). 

RATIONAL 
Specifies the horizontal and vertical offsets of the top left of 
the IFD from the top left of the Primary IFD in resolution units. 
For example, if the Primary IFD is at 400 pixels per inch, anda 
foreground layer IFD is at 200 pixels per inch and located at 
pixel coordinate (345, 678) with respect to the Primary IFD, the 
XPosition value is 345/400 and the YPosition value is 678/400 in 
inches. 
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The Primary IFD does not use the XPosition or YPosition fields. 
The XPosition and YPosition values must be specified for MRC child 
IFDs; there is no default value. 


3. New Fields 


Decode (433). 
SRATIONAL 
For Foreground and Background layers, see Section 6.2.3. 


T820ptions (435) 
LONG 
For Mask layer, see Section 5.2.3. 


ImageBaseColor (434). 
SHORT 
Count = SamplesPerPixel 


In areas of an image layer where no image data is available (i.e., 
where no strips are defined, or where the StripByteCounts entry for 
a given strip is 0), the color specified by ImageBaseColor will be 
used. 


If the ImageBaseColor field is used in an IFD that contains image 
data encoded in ITU L*a*b*, then the ImageBaseColor will be 
interpreted with the color-encoding parameters of the image data 
(i.e., color gamut, illuminant, bit/sample, and decode). If the 
ImageBaseColor field is used in an IFD that contains image data that 
is not encoded in ITU L*a*b, then the ImageBaseColor SHALL be 
interpreted as 8 bits/sample, 3 samples/pixel ITU L*a*b*. If the 
ImageBaseColor field is used in an IFD that contains no encoded 
image data, then the ImageBaseColor SHALL be interpreted as 8 
bits/sample, 3 samples/pixel ITU L*a*b*. If the fax data stream 
requires a different encoding, then transferring the default color 
value between a TIFF file and fax data stream requires a color 
conversion. 


A [T.44] stripe may contain a Foreground or Background image less 
than full stripe size, with the rest of the stripe assuming a 

default image color. In this case, the default image color is imaged 
first, followed by the image data. In Profile M, this is represented 
as a child IFD containing no encoded image data but specifying the 
default image color in the ImageBaseColor field. A second child IFD 
contains the image data. To ensure the default image color is imaged 
first, the order value in the ImageLayer field of the IFD defining 
the ImageBaseColor field MUST have a lower value than the order 

value in the ImageLayer field of the IFD defining the image data. 
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To define a child IFD specifying a ImageBaseColor but containing no 
encoded image data, 


IFD with the following settings. 


specified layer 
less than any other IFDs corresponding 
to the same layer and strip. 


RowsPerStrip: strip height 

ImageLength: strip height 

ImageWidth: full image width 

BitsPerSample: 8 

PhotometricInterpretation: 10 (ITULAB) 

SamplesPerPixel: 3 

Compression: 1 (none) 

X/YResolution: that of the Primary IFD 

XPosition: 0 

YPosition: the offset from the top of the page to 
the beginning of the strip in the 
resolution units of inches 

StripByteCounts: single 0 value 

StripOffsets: single 0 entry 

NewSubFileType: bit 4 0 (MRC) 

ImageBaseColor: desired color in 8 bit ITULAB 


For the Foreground layer image, the default value for the 
ImageBaseColor field is black. For other cases, including the 
Background layer image, the default value is white. 


StripRowCounts (559). 

LONG 
Count = number of strips. 
The number of scanlines stored in a strip. Profile M allows each 
fax strip to store a different number of scanlines. For strips 
with more than one layer, the maximum strip size is either 256 
scanlines or full page size. The 256 maximum SHOULD be used 
unless the capability to receive longer strips has been 
negotiated. This field replaces RowsPerStrip for IFDs with 
variable-size strips. Only one of the two fields, StripRowCounts 
and RowsPerStrip, may be used in an IFD. 


ImageLayer (34732). 

LONG 
Count = 2. 
Image layers are defined such that layer 1 is the Background 
layer, layer 3 is the Foreground layer, and layer 2 is the Mask 
layer, which selects pixels from the Background and Foreground 
layers. The ImageLayer tag contains two values, which describe 
the layer to which the image belongs and the order in which it is 
imaged. 
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ImageLayer[0] = 1, 2, 3. 
1: Image is a Background image, i.e., the image that will appear 
whenever the Mask contains a value of 0. Background images 


typically contain low-resolution, continuous-tone imagery. 

2: Image is the Mask layer. In MRC, if the Mask layer is present, 
it must be the Primary IFD and be full page in extent. 

3: Image is a Foreground image, i.e., the image that will appear 
whenever the Mask contains a value of 1. The Foreground image 
generally defines the color of text or lines but may also 
contain high-resolution imagery. 


ImageLayer[1]: 

1: first image to be imaged in this layer 
2: second image to be imaged in this layer 
3: 


In Profile M, more than one image can exist in a single layer. 
ImageLayer[1] specifies the order in which images within a single 
layer are to be imaged. This insures that overlapping images 
within a single layer are imaged correctly. 


If an IFD contains no encoded image data and is used only to 
specify the ImageBaseColor field, the value of ImageLayer[1] must 
be less than that of any other IFD corresponding to the same layer 
and strip to ensure the image data is interpreted as on top of the 
default color. 


In Profile M, it is possible to have only a single layer. For 
example, if a page contains only a single continuous-tone 
photograph, then only the Background layer would occur. In this 
case, the Background layer will be stored as the Primary IFD. 
ImageLayer[0] will be 1, indicating Background; ImageLayer[1] will 
be 1, as there can be no other IFDs associated with that layer. 

No Mask layer will exist. 


8.3. Recommended TIFF Fields 
See Sections 2.2.3. and 2.2.4. 
8.4. Rules and Requirements for Images 


Profile M defines a fundamental set of rules for images in the 3 
layer representation. 
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1. If more than one layer exists, then the binary Mask layer SHALL be 
present and be the primary image. The Mask layer SHALL support 
the binary data representations defined in Section 3 and MAY 
support those defined in Sections 4 and 5, with the exception that 
PhotometricInterpretation MUST be 0. If only one layer exists, 
then the image corresponding to that layer is the primary image. 


2. The Primary IFD defines and extends to the entire page boundary; 
all attached model images cannot extend beyond the Primary image. 
Resolution differences may cause some pixels to "hang over" the 
page boundary, but no new pixels should exist completely beyond 
the page extent. 


3. The Background and Foreground images SHALL support the color 
representations defined in Section 6 and MAY support those defined 
in Section 7. These images MAY optionally cover only a portion of 
the strip or page. 


4. Each Primary IFD and each MRC-specific SubIFD must have an 
ImageLayer field to specify which layer the IFD belongs to, and 
the imaging order of that IFD within the layer. 


5. Each Primary IFD must have a NewSubFileType field value set to 18, 
indicating a single page of a multi-page document (bit 1) and MRC 
(bit 4). 


6. Each MRC-specific child IFD must have a NewSubFileType field value 
set to 16, indicating MRC (bit 4). 


7. In MRC fax, each layer is transmitted as a sequence of strips. If 
the page consists of a single layer, then all strips shall be 
stored in the single Primary IFD. In this case, coding parameters 
cannot change between strips. If the page consists of more than 
one layer, then all strips of the Mask layer shall be stored in 
the single Primary IFD. All strips of the Foreground/Background 
layers SHALL be stored in separate IFDs, referenced by the Primary 
IFD’s SubIFD field, containing an ImageLayer field with 
ImageLayer[0] identifying either Background (layer 1) or 
Foreground (layer 3), and Imagelayer[1] identifying order in which 
images within a single layer are to be imaged. The TIFF XPosition 
and YPosition fields are used to indicate the placement of these 
images with respect to the primary image. 


8. When the Mask image is present, the resolution of Background and 
Foreground images must each be an integer factor of the Mask 
image. For example, if the Mask image is 400 pixels/inch, then 
the Background or Foreground image may be at 400 pixels/inch 
(400/1), 200 pixels/inch (400/2), or 100 pixels/inch (400/4). 
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8.5. Profile M: MRC Fax Profile Summary 
Recommended fields are shown with an asterisk (*). 


Required fields or values are shown with a double asterisk (**). If 
the double asterisk is on the field name, then all the listed values 
are required of implementations; if the double asterisk is in the 
Values column, then only the values suffixed with a double asterisk 
are required of implementations. 


$2 A O a N E + 
| Baseline Fields | Values 
$ A O O A E T + 
| BitsPerSample | 1**: binary mask, RGB, CMY (K) 
| | 2 - 8**: bits per color sample 
| | 9 - 12: optional 12 bits/sample 
$ e E E Ea E S + 
| Compression | 1: None (ImageBaseColor IFD only) | 
| | 3**: Modified Huffman and Modified READ | 
| | 4: Modified Modified READ | 
| | 7**: JPEG | 
9: JBIG, per T.85 
10: JBIG, per T.43 
$ A O a + 
| DateTime* | (ASCII): date/time in the 24-hour format | 
| | "YYYY:MM:DD HH:MM:SS" | 
+= papa ses Hess parao espais 2 + 
FillOrder** 1: Most significant bit first 


2: Least significant bit first 


| ImageDescription*| {ASCII}: A string describing the | 
contents of the image. 


864, 1024, 1216, 1728**, 2048, 2432, 
2592, 3072, 3456, 3648, 4096, 4864 
Note: legal widths for the Primary IFD. | 


16, 18: 

Bit 1 indicates single page of a multi- 
page document on Primary IFD | 
Bit 4 indicates MRC model 
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$ Psp A > + 
| Orientation | 1**-8, Default 1 
$ A O O N O a + 
| PhotometricInter | 0**: WhiteIsZero (Mask Layer) 
| pretation | 2: RGB 
| | 10**: ITULAB | 
$2 A O O O + 
| ResolutionUnit** | 2: inch 
$2 A O O + 
| RowsPerStrip | n: number or scanlines per strip | 
$2 A O O + 
| SamplesPerPixel | 1**: L* (lightness) 
| | 3: RGB, LAB, CMY | 
| | 4: CMYK | 
$2 A O a + 
Software* (ASCII): name € release number of 
creator software 
$2 A O S + 
| StripByteCounts** | <n>: number or bytes in each strip | 
$ A O T ET + 
| StripOffsets** | <n>: offset from beginning of file to | 
| | each TIFF strip | 
AZ hs Si Soo no ASS + 
| XResolution | 100, 200**, 300, 400 (written in | 
| | pixels/inch) | 
$2 E = + 
| YResolution | equal to XResolution (pixels must be | 
| | square) 
$2 A O E N A + 
| Extension Fields | 
$2 A O A + 
| T40ptions | 0**: required if Compression is Modified| 
| | Huffman, EOLs not byte aligned 
1: required if Compression 2D Modified 
READ, EOLs are not byte aligned 
| | 4**: required if Compression Modified | 
| | Huffman, EOLs byte aligned 
| | 5: required if Compression 2D Modified | 
| | READ, EOLs are byte aligned | 
$ A O O E a + 
| T6Options | 0: required if Compression is 2D 
| | Modified Modified READ | 
$ o EE EEE + 
| DocumentName* | {ASCII}: name of scanned document | 
E A A O E E, + 
PageNumber** n,m: page number followed by total page 
count 
$ A O O E AAA + 
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+ AS id A a ee A 


+ A O A 


+ A it A A A A 


ChromaSubSampling 


ChromaPositioning 


Indexed 


YPosition 


+ —— + —— + — + —— + — + —— 


New Fields 


+ = See ee ee A 


Decode 


+ SS Se SS A A 


ImageBaseColor 


+ ear Se ee A 


StripRowCounts 


+ = ee ee ee 


ImageLayer 


+ A E A E a feel 


T820ptions 


IFD* 


ProfileType* 


+ A A A A ay ee a ee meee ae ee 


FaxProfile* 


+ a q ha e pa q a e al lg ae po q mel 


CodingMethods* 


+ E E A A A E A 


ModeNumber* 


+ die E ae nas nl a ll ay ee es ed p 


VersionYear* 


a 
Re 
o 
o 
w 
Re 
tU 
w 
B 
y 
3 
D 
ct 
o 
ES 
n 
+— + — + — + — + — + —— + — + —— + — + — + ——+ 


+ E A A et oe ee 
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A A A o A o ey a a + 
(1,1), (2, 2)** | 
(1, 1): equal numbers of lightness and 
chroma samples horizontally & vertically 
(2, 2): twice as many lightness samples | 
as chroma horizontally and vertically | 
SS SSS E EOE R + 
1: centered | 
TRS S a Ne a Noy a a A A + 
0: not a palette-color image 
1: palette-color image 
A O A A A A A AA A A A + 
<IFD>: byte offset to FG/BG IFDs | 
A Oe ee ee oe A A Se ee A A SS SS + 
horizontal offset in primary IFD | 
resolution units | 
A a Hai e pb e a a te o y a a ll re ae Ped ab et ee + 
vertical offset in primary IFD 
resolution units | 
EAR + 
EEEE E EESE E EE R + 
minL, maxL, mina, maxa, minb, maxb: | 
minimum and maximum values for L*a*b* | 
a ee A A A Se A EE A AA Se + 
a,b,c: background color in ITULAB | 
Sa A AA A Se AA A A ee ee + 
<n>: number of scanlines in each strip | 
SS o E eS E li e ee A O a A e A A o A ee A A A ES + 
n, m: layer number, imaging sequence | 
(e.g., strip number) | 
a E a Pi en e a li a a o ah je is i a eee ae Pls ab elt e a + 
0: T.85 profile of T.82 coding | 
a a E E A at gs se A es eed eet es AA l p A a + 
IFD: global parameters IFD 
SSS SS SS eS SS Se eS Se Se eS + 
n: type of data stored in TIFF file | 
WA A AA A ae A A NA a A a se a A ie + 
n: ITU-compatible fax profile | 
cg et A Gt a fen em gs Ned em lg ef es en A + 
n: compression algorithms used in file | 
a Sd ae al o il San a A a ame Ps al A o A o ad e y o pi A a + 
n: version of T.44 standard 
i a A A SR A A A A ST pi i ge + 
byte sequence: year of ITU fax standard | 
te Oe ee a A A A EA Se Se Se AE + 
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dis 


10. 


II. 


11. 


MIME content-types image/tiff and image/tiff-fx 


The MIME content-types image/tiff and image/tiff-fx are used for 
TIFF-FX encoded image data, as defined in this document. [TIFF-REG] 
and [TIFF-FX-REG] describe the registration of these MIME content- 
types. 


Security Considerations 


This document describes a file format for Internet fax, which is a 
series of profiles of TIFF for facsimile. As such, it does not 
create any security issues not already identified in [TIFF-REG], in 
its use of fields as defined in [TIFF]. There are also new TIFF 
fields defined within this specification, but they are of a purely 
descriptive nature, so no new security risks are incurred. 


Further, the encoding specified in this document does not in any way 
preclude the use of any Internet security protocol to encrypt, 
authenticate, or non-repudiate TIFF-encoded facsimile messages. 
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Annex A: Summary of TIFF Fields for Internet Fax 


This annex includes tables which list by profile the TIFF fields used 
in the proposed fax file format. The fields are organized into 3 
categories: 


1) TIFF Baseline Fields 
2) TIFF Extension Fields 
3) New Fields. 


The tables include the allowed values for each fax profile. Entries 
other than explicit numbers are described by: 


n - single number 

n, m - 2 numbers 

a, b, c - 3 numbers 

r - rational number 

<n> - array of numbers 

<b> - byte sequence 

{ASCII} - string 

IFD - IFD byte offset 

<IFD> - array of IFD byte offsets 


A blank entry in the table indicates that the field is not used by 
that particular fax profile. 


Table A.1 TIFF Baseline Fields 


HZ + 
| Fax Profile | 
Zo | 
| Minimal | Extended | JBIG | Lossy |Lossless| Mixed | 

Ho | Bew | B&W | B&W | Color | Color | Raster | 

FLEE Content 
Field S F J e L M 

4+---------- 4+--------- 4+---------- 4+-------- 4+--------- 4+-------- 4+-------- + 

| BitsPer | 1 | 1 li, | 8 | 1, 2-8 | 1, 2-8 | 

| Sample | | | | | 9-12 | 9-12 | 

+---------- 4+--------- 4+---------- 4+-------- 4+--------- 4+-------- 4+-------- + 

Compres- 3 3, 4 9 7 10 3, 4, 7 
sion 9,10 

4+---------- 4+--------- 4+---------- 4+-------- 4+--------- 4+-------- 4+-------- + 

| DateTime | | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII} | 

4+---------- 4+--------- 4+---------- 4+-------- 4+--------- 4+-------- 4+-------- + 

| FillOrder| 2 | 1, 2 || “ay 22 |) shee (i2 | 42 | 

4+---------- 4+--------- 4+---------- 4+-------- 4+--------- 4+-------- 4+-------- + 
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4+---------- +--------- +---------- +-------- +--------- +-------- +-------- + 
ImageDes- | | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {AScII}| 
cription | | | | | | 

+---------- +--------- Ho +-------- +--------- +-------- +-------- + 

| Image- | n | n | n | n | n | n 

| Length | | | | | | | 

+---------- +--------- +---------- +-------- 4+--------- +-------- +-------- + 

| Image- | 1728 | 1728, 2048, 2432 | 864, 1024, 1216, 1728, | 
Width 2592, 3072, 3456 2048, 2432, 2592, 3072, 

| | | 3648, 4096, 4864 3456, 3648, 4096, 4864 

| | Note, for the Mixed Raster Content M profile | 
| | these widths apply to the Primary IFD. 

+---------- +--------- Ho Ho ooo Homo +-------- +-------- + 

| NewSub- | 2 jie | 2 | 2 | 2 | 16, 18 | 

| FileType | | | | | | 

Ho +--------- Ho +-------- +--------- +-------- +-------- + 

| Orien- | 1 | 1-8 | 1-8 | 1-8 | 1-8 | 1-8 

| tation | | | | | | | 

+---------- +--------- Ho +-------- +--------- +-------- +-------- + 

| Photo- | 0 | o, 1 uba: oto A E 

| metric- | | | | | 10 lazy | 
Interp- 10 
retation 

Ho Homo Ho ooo +-------- +--------- +-------- +-------- + 

| Resolu- | 2 | 2, 3 a IN [eee MiS 

| tionUnit | | | | | 

Ho Homo +---------—- +-------- 4+--------- +-------- +-------- + 
RowsPer- n n n n n n 
Strip 

+---------- +--------- Ho +-------- Homo +-------- +-------- + 

| Samples- | 1 et ie’ | T3 Ta al a 

| PerPixel | | | | | | | 

+---------- +--------- +---------- +-------- 4+--------- +-------- +-------- + 

| Software | | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII} | 

+---------- 4+--------- +---------- +-------- +--------- +-------- +-------- + 

| Strip- | n | <n> | <n> | <n> | <n> | <n> 

| Byte- | | | | | | 

| Counts | | | | | | 

+---------- +--------- Homo +-------- +--------- +-------- +-------- + 
Strip- n <n> <n> <n> <n> <n> 
Offsets 

+---------- Homo Homo +-------- +--------- +-------- +-------- + 

| XResolu- | 204 | 200, 204, 300 | 100, 200, 300, 400 

| tion | 200 | 400, 408 | 

+---------- +--------- +---------- +-------- +--------- +-------- +-------- + 
YResolu- | 98, 196 | 98, 196, 100, 200 100, 200, 300, 400 
tion 100,200 | 300, 391, 400 

+---------- +--------- +---------- +-------- +--------- +-------- +-------- + 
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Table A.2 TIFF Extension Fields 


+-------------------- --- = 5 5 == + 
| Fax Profile | 
$o--- 7-77-77 = 5-5-5 7-5-5 5-5-5 55-55-5555 5-5-5 | 
| Minimal | Extended | JBIG | Lossy |Lossless| Mixed | 
Ho | Bew | B&W | B&W | Color | Color | Raster | 
| TIFF | | | | | | Content | 
| Field | S | F |J | C | L | ™M 
+---------- +--------- 4+---------- +-------- +--------- +-------- +-------- + 
Chroma- | | | 1 | | 1 | 
Position-| | | | 
ing | | | | 
+---------- +--------- +---------- +-------- +--------- +-------- +-------- + 
Chroma- | | | | <iis |] <1, 1> | 
SubSampl- <2, 2> LS 
ing 
+---------- +--------- 4+---------- +-------- +--------- +-------- +-------- + 
Document - | | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII} | 
Name | | | | | | 
+---------- +--------- +---------- +-------- +--------- +-------- +-------- + 
| Indexed | | | | | 0,1 | 0,1 | 
+---------- +--------- +---------- +-------- +--------- +-------- +-------- + 
Page- |n m |n m n, m |n m | n, m n, m | 
Number | | | | 
+---------- +--------- +---------- +-------- +--------- +-------- +-------- + 
| SubIFDs | | | | | | <IFD> | 
+---------- +--------- +---------- +-------- +--------- +-------- +-------- + 
| T4Options| 0, 4 107, Ls | | | Orig. | 
| | 4, 5 | | | 4, 5 | 
+---------- +--------- +---------- +-------- +--------- +-------- +-------- + 
| T6Options | | o | | | | o 
+---------- +--------- 4+---------- +-------- +--------- +-------- +-------- + 
| XPosition| | | | | | r | 
+---------- +--------- +---------- +-------- +--------- +-------- +-------- + 
| YPosition| | | | | | r | 
+---------- +--------- +---------- +-------- +--------- +-------- +-------- + 
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Table A.3 


—— +  _ —m 


+ + + + +— + + + + + 

| | p | | | | | | | | | | | | 

| | ug | | | | | l | | | | | | 

| | oo oO | | | | | | | | | | | | 

| | OvpY | | | | | | | E | | | | 

| | xX ngs | | | | 1 A | 1a | | LA | 

| l-o go | | | | I ul | fy Los | er | | 

i AA S i EEL] EAE S A A e 

| | —— + — t tH + ——— + —— + —— + —— + —— + —— 

| Ia | | | | | | | | | | | | 

| Ia | | | | | | | | | | | | 

| 1 ow | | | | | | | | | | | 

| IHO | | | | | | | | | | | | 

| Llad AI | | | 1 A | 1a | | | | | 

| Inao | | | | I ul | By | | | | | 

| I 00 | | a | Ivi LA | | | l a 

| 14 | | | | | | | | | | | 

| Y e Y —— Y O e A 4 e $+ a  — — 

| | | | | | | | | | | | | | 

| | | | | | | | | l | | | | 

| I>” su | | | | | | | | | | | 

| | no | | | | | | | | | | | 

| Iad 01 | | | | | | | | | | | 

| o!oo | | | | 1 A | 1a | | | | | 

lat Ho | | | | I ul | fy | | | | | 

l-A l | | Ie | Ivi LA | | | | Is 

IWH | | | | | | | | | | | | | 

A I= +t t a MHM 

1 4 | | | | | | | | | | | | | 

IA | | | | | | | | | | | | | 

| MO) | | | | | | | | | | | 

Lx IA | | | | | | | | | | | | 

1 o1Os8 bl | | | | | 1a | | | | | 

IeM | | l | | | | fy | | | | 

| l | | Is l | Ie LA | Ies | | hos 

| | | | | | l | | | | | | | 

| | —— + —— + —— + + ——— + — + + ——— + —— + + —— + —— + 

| | | | | | | | | | | l | | 

| xe) | | | | | | | | | | | | 

| 1 O | IES | | | | | | | | | | 

| | Oz | | | | | | | | | | | | 

| ISS kl fe ae Md | | l | | | | l | 

| | om | lod | | | | | | | | | | 

| 1p | | | | | | 1a | | l | | 

| | x | Gt, oi | | | | By | | | | | 

l | fl Kig 1 oO | Ie | | LA | | | | | 

| | | | | | | | | | | | | | 

| Y —————— t t —— M IMMM HMMH 

| | | | | | | | | | | | | | 

| lod | | | | | | | | | | | | 

| Ig | | | | | | | | | | | | 

| | €=z | | l | | | | | | | | | 

| Idg vnl | | | | | | | | | | | 

| | aa | | | | | | | | | | | | 

| lod | | | | | | | | | | | l 

| 1S | | | | | | | | | | | 

| | | | | | | | | | | | | | 

+— E ———— + MMMH 
| | ae | | | | | | | | gl | 
| | 1 x | Le hehe SRA] | | | l | O | | 
| pr o Io | 30 0 | | o!llrtiatl | n | | | o 
| Ol X | i I oov!loeadi oi F31H0f 101 | Bh On yg lA 
lol enig 1g¢0!o0oMnd!1 701 ql e@BH! OY I O!le00ll Ola 
IHOIHOI CSIAS nO! oO1rt1ryni gent noi IAIL DOI oQinvno 
I B-A ll OG! oviDvyplge >Re! o!;lxwo!loun! @HAINY! BHOITDE! OD 
| kw I OH! AB!OO!l OH B®! O01 GBHYIlHABGOIEBInQaI ea! os1 ah 
! [MATO IO [OPA 10 IRA OA AA BOILHMIZZ| MK 
+ —— + + + —— + — +— + + ——— + —— + + + —— + 
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fui pepa pr Pos Seis nota pasase + 
| strip- | | | | | | <n> | 
| RowCounts | | | | | | | 
has ps a Haas +-------—- a pd + 
| Version- | | | | <b> | <b> | 

| Year | | | | | | | 
ste foree es ie pastas Jenseni pesas 35 sos + 


Annex B: List of technical edits to RFC2301 


This Annex lists technical differences between this document and 
RFC 2301, the Proposed Standard File Format for Internet Fax. 


E A O O O E + 
| No.| Section | Technical Edit 

+----4+--------- ER + 
| 1. | 5.2.1 | Added Fillorder=1 to Profile J | 
+----+--------- is Soe eae ene ae eee + 
EE | Constrained ResolutionUnit to 2 (i.e., inch) for| 
| (21 | all color profiles, per ITU-T Recommendations | 
| 12 20d | | 
+----+--------- A O O O NT + 
Be, MA | Deleted ColorMap field; it re-encoded the color | 
| [TA | palette already in the T.43 data stream 
O A O O O E + 
Ae A | Changed TAG value of Indexed field from 364 to | 
| | | 346 to agree with Section 8.2.2 and Ref. [TTN1] | 
O A O O O + 
MS 118231 | Added text clarifying the use of ImageWidth | 
| | | when Background or Foreground layer is Primary | 
We, | IFD | 
A a ee + 
|) Ge. [8,23 | Changed field name from DefaultImageColor to | 
| | | ImageBaseColor; 

O A O O O + 
ee BD | Added Compression=1 for ImageBaseColor IFDs | 
t----4+--------- A nn O N + 
RE: 5ni | Redefined compression = 9 to be T.82 (JBIG); | 
| [SF ZES | added T820ptions field, with a default value (0) | 
| | | corresponding to the T.85 application profile | 
+----+--------- PE a nn O AN + 
iga | esas | Added GlobalParametersIFD, ProfileType, | 
| [A7 | FaxProfile and CodingMethod to the New Fields | 
| | | portion of Profile F, per Sec. 2.2.4 
+----+--------- fa O O + 
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O si + 
| 10.| 6.2.1 | Deleted BitsPerSample=12 as an option when | 
6.2.3,6.4| Compression=7 due to lack of interop testing. 
Table A.1 
4----4+--------- HS SSS 22222239 ee a ee ee SS + 
| 11.|8.2.1,8.4| Deleted PhotometricInterpretation=5 in Profile M| 
| |Table A.1| due to insufficient interop testing. 
+----+--------- A O O E E + 
12.|7.2.1,7.4| Deleted BitsPerSample=13-16 for Palette-color 
8.2.1,8.5| due to lack of interop testing. 
| |Table A.1| | 
a E A he aaa A SS aa ae Sse SaaS + 
| 13.| Annex B | Deleted Annex B due to discontinued use of | 
| | | application parameter; Annex C renamed Annex B | 
A A O O O O E + 
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